Updated: Tracking Down EXC_BAD_ACCESS Errors with NSZombieEnabled in Xcode 4
Posted on January 26, 2012 by John Muchow in Debugging
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:
Related posts:
- Tracking Down EXC_BAD_ACCESS Errors with NSZombieEnabled
- Compare NSString Objects (Updated)
- Download and Install Older Versions of Xcode (Xcode Previous Releases)
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?
[Reply]
John Muchow Reply:
January 29th, 2012 at 12:26 pm
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.
[Reply]
Neil Reply:
January 30th, 2012 at 5:08 am
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?
[Reply]
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.
[Reply]
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.
[Reply]