iOS Development: Why are the retain counts for my view controller so strange?

Question

I'm diving into iOS development and I'm building a navigation based app that wasn't fully releasing one of the views that was being pushed onto the nav stack. This is problematic because the view controller is never being deallocated, so the memory it uses just builds up every time the view controller is pushed on to the stack. So after investigating the issue, I found the retain counts for the view controller were really strange. The view controller in question is pushed on to the stack once a countdown timer reaches zero.

Here's the code that creates the view controller in the timer callback, displays its retain count, and pushes it onto the nav stack...

-(void)updateCountDownTimer   //Defined in MyViewController_A class
{
    [self setTimeRemaining:([self timeRemaining] - 1)];

    [[self countDownLabel] setAlpha:1];
    [[self countDownLabel] setText:[NSString stringWithFormat:@"%d", [self timeRemaining]]];

    //Fade out the current time
    [UIView beginAnimations:@"FadeAnimation" context:nil];
    [UIView setAnimationDuration:1];
    [[self countDownLabel] setAlpha:0];
    [UIView commitAnimations];  

    if ([self timeRemaining] == 0) 
    {       
        MyViewController_B *myvc_b = [[MyViewController_B alloc] initWithNibName:@"MyView_B_iPhone" bundle:nil];
        [[self navigationController] pushViewController:myvc_b animated:YES];
        NSLog(@"updateCountDownTimer: %d", [myvc_b retainCount]);
        [myvc_b release];

        [[self countDownTimer] invalidate];
        [[self countDownLabel] setHidden:YES];
    }
}

and here's the code that pops the view controller off the nav stack once the pause button is pressed...

- (void)pauseButtonPressed:(id)sender
{
    //Stop the timer
    [puzzleTimer invalidate];

    NSLog(@"pauseButtonPressed before pop: %d", [self retainCount]);

    //return to the previous view
    [[self navigationController] popViewControllerAnimated:YES];

    NSLog(@"pauseButtonPressed after pop: %d", [self retainCount]);
}

and here's the console output that shows really strange retain counts throughout the process...

2010-12-02 17:50:38.062 MyApp[821:307] updateCountDownTimer: 5
2010-12-02 17:50:40.453 MyApp[821:307] pauseButtonPressed before pop: 2
2010-12-02 17:50:40.462 MyApp[821:307] pauseButtonPressed after pop: 4

I'm new to iOS development, but the code seems pretty straightforward to me, so I don't know what I'm missing.

Thanks so much in advance for your wisdom!

UPDATE: It looks like the Leaks instrument is reporting a leak on the line of code that pushes the previous view controller onto the stack (that is, the view controller responsible for pushing the view controller in question). The code is once again very straightforward, so I don't know why it's reporting a leak...

MyViewController_A *myvc_a = [[MyViewController_A alloc] initWithNibName:@"MyView_A_iPhone" bundle:nil];

[[self navigationController] pushViewController:myvc_a animated:YES]; //<--Leak being reported here

[myvc_a release];

*UPDATE:*Found the problem, it was just as everyone was saying and the same problem as was shown in the link posted in the comments below, I had live objects still referencing my view controller, which prevented it from deallocating. In my case, I had two timers that were targeting my view controller and those timers weren't being invalidated before I popped the view off the stack, which meant there were two live objects still referencing the view controller. Here's a snippet I found in the Apple docs which uncovered the problem...

Perhaps more importantly, a timer also maintains a strong reference to its target. This means that as long as a timer remains valid (and you otherwise properly abide by memory management rules), its target will not be deallocated.

Anyhow, thanks again to everyone who helped!

Answer 1

You're not missing anything -- instances of UINavigationController just do strange, strange things to the retain count internally.

You should only worry about the retainCount if you see a specific memory leak that you're trying to patch up. In this case, of course, you DO have a problem... the retainCount just doesn't help, since it's so bizarre.

You might check if dealloc is getting called on MyViewController when you do the pop. Also, before you test, comment out the lines that check the retainCount. Calling retainCount will sometimes add to the retainCount.

To really nail down what's going on, in Xcode, go to the Run menu, and select Run With Performance Tool > Leaks. Push and pop that view controller, and you should see it pop up as a leak. You'll be able to see all of the retain and release calls on the object.

If you're really stuck, Apple's guide to Finding Leaks has a few more clever solutions. Good luck!

Answer 2

There is nothing wrong with your code as far as memory management is concerned.

You should not rely on retain counts to check if your objects are being released properly as the system will also be retaining what it needs and releasing when appropriate. For instance when you add your view controller to the stack it gets retained by the nav controller along with its subviews and when it's popped out it gets send a release message which propagates all of its subviews.

The general rule is if you alloc, retain or copy an object, it is your responsibility to release it. Everything else is dealt with by the system and will be flushed with the auto release pool.

Answer 3

Never, ever, ever look at the retain counts of your objects. They should not be used programmatically, and are misleading when you are trying to debug your code.

Here's why: You know that in your code, you are making calls to retain and release to manage your retain count. But you may also be making calls to -autorelease, which causes your retain count to be decremented at a later date over which you have little or no control. Worse, any time you pass a reference to your object to an object that you do not control the implementation of (which is likely to happen to most of the objects you create), the receiving object may make its own adjustments to the retain count - and that object may pass your object to yet other objects, which also adjust the retain count.

The point is, you should not ever look at the retain count of your objects for any reason at any time. They will only serve to confuse you. Your job is to manage your own claims to an object correctly, and trust that the code written by others is doing so as well.