Performance tool - leak

Question

If I testing my codes with performance tool - leaks, and it doesn't detect any leaks. Does that mean the codes is not leaking any memory?

I have a Jail-broken iPhone, which I can monitor the available memory. If anyone knows, it's SBSettings. I tested my app which has a UITableView and I can see the available memory dropping when I am scrolling through the tableView. From 300MB to 30MB, where it seems like it can't drop further. It usually doesn't drop that much with other apps other than games. I am using a custom UITableViewCell with 2 buttons, 1 textView and 3 UILabels.

So, yeah. If performance tool does not detect any leak, am I safe?

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {
    static NSString *CellIdentifier = @"StatusTableCell";

    StatusTableCell *cell = (StatusTableCell *)
    [tableView dequeueReusableCellWithIdentifier:CellIdentifier];
    if (cell == nil) {
        NSArray *topLevelObjects = [[NSBundle mainBundle]
                                    loadNibNamed:@"StatusTableCell"
                                    owner:nil options:nil];
        for (id currentObjects in topLevelObjects){
            if ([currentObjects isKindOfClass:[StatusTableCell class]]){
                cell = (StatusTableCell *) currentObjects;
                break;
            }
        } 
        [cell.cancelButton addTarget:self action:@selector(cancelButton:) forControlEvents:UIControlEventTouchUpInside];
    }
     /// some other stuff
     return cell;
}

The answers to this question might also apply here: [In CocoaTouch (iPhone OS) how do I find/eliminate leaks that the Instruments Leak tool doesn't find?](http://stackoverflow.com/questions/281764/in-cocoatouch-iphone-os-how-do-i-find-eliminate-leaks-that-the-instruments-leak) — Brad Larson, Sep 27 '11 at 18:57

Saurabh Passolia · Answer 1 · 2011-09-27T14:41:22.057

1

You should consider value of LiveBytes in performance tool if it is increasing with app running, it is an issue. This might happen with tableviews if you are not using reusable cells. Check for it if you have reusable cells or not.

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath
{
    UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:@"reusablecell"];

    if(!cell)
    {
        cell = [[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault reuseIdentifier:@"reusablecell"];
        [cell autorelease];

    }
//update cell here

return cell;
}

edited Sep 27 '11 at 14:41

answered Sep 27 '11 at 13:14

Saurabh Passolia

8,099
1
26
41

I can see that the Live Bytes does keep increasing as I scrolls the tableView. That's weird as im reusing cells as posted on my question. – Gavin Sep 27 '11 at 14:37
most probably, you are not using reusable cells in "cellForRowAtIndexpath" see my sample code updated in my post. – Saurabh Passolia Sep 27 '11 at 14:40
I have verified by adding NSLog inside a else statement and yes, I am re-using cells. The `if(cell == nil)` is only called twice and the rest of the time, it's not nil. – Gavin Sep 27 '11 at 14:49
Oh nvm, the identifier name I set for my UITableViewCell was being the same as it's class. Not having any problem after changing to another identifier name. – Gavin Sep 27 '11 at 14:56
that's great..it worked for you..but weird! but this solution works at many instances...!! – Saurabh Passolia Sep 27 '11 at 15:37
No worries, your code looks fine. The weird thing is I have to use a name for my cell identifier that differs for it's class name. Like StatusTableCellIdentifier. – Gavin Sep 27 '11 at 23:15

score 1 · Answer 2 · answered Sep 27 '11 at 13:28

No, you're not necessarily safe.

A memory leak occurs when the program no longer has a reference to an object. So if an object is released, but an object it was retaining is not (not released properly in the dealloc method, for example), you get a leak.

However, if the owning object is never released itself, no leak is detected.

To look for these kinds of memory problems, run the allocations instruments tool. Click on the Mark Heap button, and perform some kind of repeatable action in the app (for example, select a row in a table view to push a detail view on to the nav stack, then tap the back button). Click on the Mark Heap button again. Then repeat the action a few times. Ideally you should see no heap growth, and no persistent objects between heap shots.

Performance tool - leak

2 Answers2