views:

1822

answers:

2

I'm pushing a view controller onto my navigation controller's stack from within my TableViewController's didSelectRowAtIndexPath method as so:

MyViewController *myViewController = [[MyViewController alloc] initWithNibName:@"MyViewController" bundle:nil];
MyAppDelegate *appDelegate = (MyAppDelegate *)[[UIApplication sharedApplication] delegate];
MyObject *myO = (MyObject *)[appDelegate.myOs objectAtIndex:indexPath.row];
myViewController.amount = myO.amount;
[self.navigationController pushViewController:myViewController animated:YES];
[myViewController release];

If I uncomment that last line then the app crashes upon return with an error:

-[CALayer release]: message sent to deallocated instance 0xd4f860

Digging in a bit further I find the crash can further be narrowed down to the call to [super dealoc] within MyViewController's dealoc method. By uncommenting "[super dealoc]" we don't crash.

I'm having trouble narrowing this down further. "super" would be the UIViewController class and I can't further investigate that dealoc method...can I? Maybe there's a way to see what exactly 0xd4f860 was pointing to but I'm not aware how? Any ideas?

+3  A: 

You're looking in the wrong place -- the problem is that myViewController is getting released (or autoreleased) too many times.

The code you have posted looks correct, so I'd look at MyViewController's code to see if it ever releases itself, or somehow causes itself to be released by other means.

You could also override the release method, set a break point and see if you can narrow it down that way... e.g.

- (void)release {
    [super release]; //Set breakpoint here
}
Daniel Dickison
Just tried overriding the release method and put a break there... it get's called 21 times on the way in (i assume triggered by the didSelectRowAtIndexPath) and then another 8 or so when backing out of the view. Not sure what I should be looking for...a whole lot of framework calls in there ("Purple"?!?, etc...)
Meltemi
mythogen brings up a good point -- you should be looking for places where the view is getting released (that's what's ultimately causing the exception, when it tries to deallocate an already-gone layer.)
Daniel Dickison
Found the problem, I think. At least it's not crashing anymore. I had 2 instances of a UIView subclass that were subviews of MyVC's view...but also needed to communicate back up to MyVC so had a property for it. I set up that property with assign (instead of retain) as per, ironically, your instructions in a comment here: <http://stackoverflow.com/questions/1145380>. It makes sense why I should NOT want to retain the VC so I wouldn't end up with a retain cycle...but w/out it I crash. I'm, obviously, still misunderstanding something here. Welcome the advice/criticism if you have the time...
Meltemi
Just reread the chapter on Retain Cycles in the Memory Management Programming Guide for Cocoa and yes, you are correct in saying that the "children" should not retain their "parents". So why then when I had my subviews ASSIGNing the VC to a property and neither of them releasing it upon dealoc would it crash? Yet, when I have them both RETAIN and then release everything's peachy? Sorry for all the noobness...would really like to understand this though..
Meltemi
That sounds like your custom subviews are doing something wrong with regards to retaining and releasing its properties, or they may be trying to send messages to their delegates (superview) even after they should've been deallocated. You may want to post some of the relevant subview-superview-controller memory management and messaging code.
Daniel Dickison
A: 

Are you releasing myViewController.view anywhere?

mythogen