Testing if an object has been deallocated

Question

I have a situation where occasionally my -tableView: numberOfRowsInSection: method asks for the count of a deallocated NSArray. I'd like to be able to test for this array being deallocated in a way that's safe and doesn't make a call to a zombie.

My code currently looks like:

-(NSInteger)tableView:(UITableView *)table numberOfRowsInSection:(NSInteger)section
{
    if (! self.offers){
        return 0;
    }
    return [self.offers count];
}

I just debugger-stepped through this and observed it passing the ! self.offers test and then crashing brutally on [self.offers count]. I have NSZombies turned on, and at that line I get the NSLog message:

-[__NSArrayM count]: message sent to deallocated instance 0x283dc0

So whatever self.offers is, at this point, is not nil, but is also not pointed at anything valid. How do I test for that?

EDIT: Thanks for the tough-love, friends. I've figured out why I've been having trouble with my memory management--it's actually been an issue of delegate relationships lingering longer than they were useful. See here for the full answer to my problem: http://stackoverflow.com/questions/3095995/managing-calls-to-objects-that-get-deallocated-when-the-view-is-backed-out-of

Answer 1

It's not possible to "test" for this-- once an object is deallocated, it's gone, and the pointer to it is effectively garbage. Doing anything with it is liable to crash.

Sorry to be the bearer of bad news, but the only way to get this to work right is to make sure the memory management around (in this case) offers is correct at all uses-- retain and release correctly at all the points where that instance variable is manipulated, and it will never be non-nil garbage.

You should try running the static analyzer (Build->Build and Analyze) to start with-- this tool can help flag memory management pattern issues without a lot of extra digging on your part.

Answer 2

You should avoid the problem by fixing the code so it does not deallocate the array when you obviously still need it.

Answer 3

This might not be relevant to your question (testing if it is deallocated) - but it seems like your offers array has the same or longer lifetime than your UITableViewController, are you certain you are retaining this array or that you aren't accidentally releasing it somewhere else.

Answer 4

I concur with what quixoto has said above.

Another thing you have to ask yourself is, is my application designed correctly? A tableview relies on a datasource to populate it (which in your case is the offers array), so if you're deallocating it somewhere in the code then you need to step back and rethink your design.

If you're testing for whether it's deallocated because you're trying to 'fix' it from a previous problem, then it might be worth looking into your code to see where it is being retained/released.