Why is Instruments reporting memory leaks in this code?

Question

Quick question, Instruments is reporting a leak here...

MyViewController *myVC = [[MyViewController alloc] initWithNibName:@"myView" bundle:nil];     
[self.navigationController pushViewController:myVC animated:YES];  //<<<<---- !00% leak according to Instruments
[myVC release];

I understand the myVC is retained by the nav controller, so I assume the nav controller releases them when the view is popped off the nav stack?

Also, there's another tricky one in one of my loops, the static analyzer is reporting a potential leak here...

//Walk through the scheduled alarms and create notifications
NSMutableArray *fireDates = [[NSMutableArray alloc] init];
for(NSDate *fireDate in fireDates)          //<<<<---- Static analyzer is reporting potential leak here
{
     UILocalNotification *localNotif = [[UILocalNotification alloc] init];
    if (localNotif == nil)
    {
        [fireDates release];
        return;
    }

    localNotif.fireDate = fireDate;  
    localNotif.timeZone = [NSTimeZone defaultTimeZone];

    localNotif.alertBody = [NSString stringWithFormat:@"%@", alarm.Label];
    localNotif.alertAction = NSLocalizedString(@"Launch", nil);

    localNotif.soundName = UILocalNotificationDefaultSoundName;

    localNotif.userInfo = infoDict;
    localNotif.repeatInterval = NSWeekCalendarUnit;

    [[UIApplication sharedApplication] scheduleLocalNotification:localNotif];
    [localNotif release];

}
[fireDates release];

Do I need to somehow release fireDate?

Thanks in advance for your help!

Answer 1

These snippets are both fine, as snippets go. Without seeing your full code it's impossible to say if you don't do something silly elsewhere. Do you ever release your navigationController (in your app delegate -dealloc, likely)? That's a leak that doesn't mean much, but it could be what is triggering the first warning.

---

Edit: with regards to the second snippet, the code looks fine (though the shortcut return case will bother some coders, who would rather see a break statement). The static analyzer may be bothered by the lack of a [localNotif release] (even though it's obviously unnecessary) in the conditional return.

Answer 2

In the first snippet, what is being leaked? Instruments will tell you the line where it was allocated, which is often not the line "responsible" for the leak (of course, line numbers tend to be off because it gives you the return address, not the calling address). I'm assuming it's MyViewController being leaked, and that instruments is actually complaining about alloc (look in the backtrace, cmd-E I think).

If you click on the arrow next to the memory address (you might have to click around a bit and hover over the leak address; I don't remember) you'll see all the alloc/retain/release/autorelease/malloc/free/CFRetain/CFRelease calls on that address. Ignore the ones before alloc (those are for a previous object which happened to live at the same address). Match retains and (auto)releases. You can match an autorelease with the corresponding (delayed) release, because the delayed release will happen when NSAutoreleasePool is release (which is evident in the stack trace). Look for a retain without a matching (auto)release. That's the leak.

In the second case, it helps if you tell us what Clang SA is telling you (click the little triangle on the left and it expands to show you the control-flow where the leak occurs).

But I don't think the loop runs at all, because fireDates is empty.