Updated: Tracking Down EXC_BAD_ACCESS Errors with NSZombieEnabled in Xcode 4

In a previous post Tracking Down EXC_BAD_ACCESS Errors with NSZombieEnabled I explained how the environment variable NSZombieEnabled can help track down EXC_BAD_ACCESS errors, which are typically caused by attempting to access objects that have already been released.

With Xcode 4 the process for setting NSZombieEnabled is different than in earlier versions of Xcode. To configure zombies, enter ⌥-⌘-r (alt-command-r). Once the dialog is shown, choose the option Enable Zombie Objects

When using a zombie, any message sent to an object that has already released will result in an exception being thrown, which will look similar to the screenshot below:

  1. 0x4e04610 – once you have this little nugget of information, what can you do with it? I’m often getting these pop up in the debugger. I presume they are addresses in memory. How can having that address help you debug?

    • With the example shown, I believe 0x4e04610 is the object that has been released, which causes the error. If I were trying to find the offending code, I would search the code for location(s) where SandboxViewcontroller is released.

      • Thanks. In a situation in which you are not sure which object is referred to, is there a way to directly trace what type of object it was and/or when it was allocated?

  2. With the example shown, 0x4e04610 should be the object SandboxViewcontroller, which causes the error. If I were trying to find the offending code, I would search the code for location(s) where SandboxViewcontroller is released.

  3. It sometimes helps to override – (oneway void) release for the offending class and NSLog() something to the effect that it is being called. And, of course, so you can throw a breakpoint on it and see when it is being called, so you can crawl back up the release stack and see what’s at the root of the problem.

Comments are closed.