views:

451

answers:

2

Instruments tells me there's a mem leak in this code, but I can't seem to find it....any help? sorry or the newbie question.

- (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath
{
    int altoBufferCelda = 26;
    Mensaje *msg = (Mensaje *)[model.mensajes objectAtIndex:indexPath.row];

    CGSize txtSize = [msg.texto sizeWithFont:[UIFont systemFontOfSize:17.0f] constrainedToSize:CGSizeMake(222, 222)  lineBreakMode:UILineBreakModeTailTruncation];

    [alturasDinamicas setObject:[NSNumber numberWithFloat:(txtSize.height + altoBufferCelda)] forKey:[NSNumber numberWithInt:indexPath.row]];

    return txtSize.height + altoBufferCelda;     
}
A: 
toast
should I ignore this leak? or try something different? thanks!
nico
That's not correct. [NSNumber numberWithFloat:] returns an autoreleased object. You're right that there's no GC on iPhone, but there definitely ARE autorelease pools. I don't see a leak in the actual code. It's *possible* there's a leak in the UIKit framework itself.
Dave DeLong
Autorelease pools aren't the same as garbage collection; if an autoreleased object isn't retained then it will be released at the end of the current event, and this is true on the iPhone as well as on OS X. Garbage collection releases objects once they are out of scope and no other object can have access to them (they are unreachable). numberWithFloat will return an NSNumber object which is autoreleased, so doesn't have to be released as it is not retained in the method above.
Perspx
But isn't the autorelease pool only drained when the application exits?
toast
And by which I mean, since the autorelease pool won't be drained until the application exits, any thing in the pool will hang around indefinitely while your application runs.
toast
@toast: that's correct that an autorelease pool hangs around, but that is fundamentally different from a memory leak. A leak is when a reference to a retained pointer is *lost*. Autoreleasing just delays the release of the pointer.
Dave DeLong
BTW, I hate reference counting :D
toast
it's not THAT bad. I think it's infinitely superior to manually malloc'ing and freeing memory. That gets very complex. Also, another note about autorelease pools - they're objects just like anything else, so you can create and destroy them as needed. I would highly recommend that when dealing with memory constrained environments (like the iPhone). They can significantly lower your overall memory footprint.
Dave DeLong
I just feel that reference counting is half of one way and half of another. Either, I manage the memory myself or the environment handles it for me.
toast
@toast: The autorelease pool is drained periodically, usually during each iteration of an application's run loop.
dreamlax
A: 

I cannot see any memory leak in your code. As toast points out, Instruments isn't always accurate. This is mostly because even the code from the Apple Frameworks contains memory leaks, which are reported by Instruments too.

If you are using XCode 3.2 you can choose Build and Analyze from the Build menu which scans your code for errors normally undetected by the compiler. This will show you many possible memory leaks resulting from forgetting to release an object.

frenetisch applaudierend