detecting double free object, release or not release ...

Question

Hello,

If we have this code in our interface .h file:

@interface CarModelSelectViewController : UITableViewController {

NSString *fieldNameToStoreModel;
NSFetchedResultsController *fetchedResultsController;
NSManagedObjectContext *managedObjectContext;
DataEntered *dataEntered;


}


@property (nonatomic, retain) NSString *fieldNameToStoreModel;

@property (nonatomic, retain) NSFetchedResultsController *fetchedResultsController;
@property (nonatomic, retain) NSManagedObjectContext *managedObjectContext;
@property (nonatomic, retain) DataEntered *dataEntered;


@end

In our implementation file .m we must have:

- (void)dealloc {

[fieldNameToStoreModel release];
[fetchedResultsController release];
[managedObjectContext release];
[dataEntered release];

[super dealloc];
}

The 4 objects are assigned from a previous UIViewController, like this:

UIViewController *detailViewController;

detailViewController = [[CarModelSelectViewController alloc] initWithStyle:UITableViewStylePlain];
((CarModelSelectViewController *)detailViewController).dataEntered = self.dataEntered;
((CarModelSelectViewController *)detailViewController).managedObjectContext = self.managedObjectContext;
((CarModelSelectViewController *)detailViewController).fieldNameToStoreModel = self.fieldNameToStoreModel;

[self.navigationController pushViewController:detailViewController animated:YES];
[detailViewController release];

The objects that now live in the new UIViewController, are the same as the previous UIViewController, and I can't release them in the new UIViewController ?

The problems is that sometimes, my app crashes when I leave the new UIViewController and go to the previous one, not always. Normally the error that I'm getting is a double free object.

I've used the malloc_error_break but I'm still not sure wich object is.

Sometimes I can go from the previous UIViewController to the next one and come back 4 or 5 times, and the double free object appears.

If I don't release any object, all is working and Instruments says that there are no memory leaks ...

So, the final question, should I release those objects here or not ?

Thanks,

m.

edit:

the fetchedResultsController.delegate is always nil, as in this view the fetched objects doesn't change, and the NSFetchedResultsControllerDelegate is not in the @interface .h file.

edit 2:

Added the declaration propoerties of the interface file, sorry!

Answer 1

If you care about an object, you retain it. If you retain it, you release it. This is all of the law, the rest is just commentary.

Most likely you are incorrectly declaring your @properties and are failing to include the "retain" attribute in them.

Note that you should be declaring detailViewController as a CarModelSelectViewController* rather than declaring it as a UIViewController and then casting it every time you use it.

You should read the Memory Management Programming Guide, and specifically Practical Memory Management. Cocoa memory management is actually quite simple. If you always use accessors and learn the three magic words, you will seldom have much trouble.

Answer 2

You are correct to release them in your dealloc method. It seems that they are being over released somewhere else. I recommend you use Instruments with NSZombieEnabled turned on. (Use the Object Allocation instrument, click on the 'i' button, and check "Enable NSZombie detection". I believe it requires you to use the Simulator for that.) When the zombie is found you can track the life of the object and see exactly where it's being retained and released.

Answer 3

If you are doing any custom initialization for CarModelViewSelectController it would be useful for us to see that.

Also, is your UINavigationControllerDelegate doing any memory management?

Answer 4

Finally I found it :-)

Once the malloc_error_break has been enabled, XCode stopped where the error was with the addres of the object, a print of the object in the console gave me the exact object, and this object wasn't in those views that I was releasing, so the problem was in the very first view that was calling my subsequent views ...

thanks,

regards,

m.