views:

587

answers:

2

I have a crash taking place when an NSAutoreleasePool drains. Presumably the pool is trying to deallocate an object that has been prematurely released by another piece of code. The crash I have is in the midst of objc_msgSend as it is trying to send a message to an object that doesn't exist anymore.

Given the stack state, what tips/tricks/processes/gdb commands do I have at my disposal to get information about the object in question and/or the point at which the illegitimate deallocation took place?

+2  A: 

If you use NSZombieEnabled you can at least figure out what class the object is.

Wevah
While correct, tequilatango's answer provides the answer along with some useful details.
bbum
Quite true. I could have at least provided a link to external information.
Wevah
+5  A: 

If you have a hunch that it is a premature deletion, enable zombies to confirm your hypothesis and then debug what is going on. When you enable zombies, objects are not really destroyed, but set to a zombie state, which helps you to detect when they are accessed after they dealloc is called. Read more from NSZombieEnabled

tequilatango
Additionally, you can use Instruments' Object Alloc instrument to track the retain/release events of the object that was prematurely released. It isn't the autorelease pool's -release that is the problem, but some prior -release, typically.
bbum