Debugging EXC_BAD_ACCESS in an iPhone app

Question

Here's my stack trace. Where do I start to figure this out? I've tried a ton of NSLog()s and I can't track it down.

#0  0x94e9ced7 in objc_msgSend ()
#1  0x04936318 in ?? ()
#2  0x0259b252 in __CFRunLoopDoObservers ()
#3  0x0259a65f in CFRunLoopRunSpecific ()
#4  0x02599c48 in CFRunLoopRunInMode ()
#5  0x02ae7615 in GSEventRunModal ()
#6  0x02ae76da in GSEventRun ()
#7  0x0061dfaf in UIApplicationMain ()
#8  0x000051cc in main

Answer 1

When the app crashes with that stack trace, open the debugging console.

If the crash is in the simulator, type this:

display /s $ecx

If on the device, type this:

display /s $r1

Make sure NSZombieEnabled is OFF when you are doing this.

It will print the name of the method the system is trying to call.

The way this works is, when it crashes it crashes trying to access a method to call that does not exist. So the name of the method is held in a register as a C-String, and those lines grab it from the register and print it out.

Answer 2

Here's how I tracked this down.

First, I went all over the place using:

NSLog(@"%s", __PRETTY_FUNCTION__, nil);

in order to get as close as possible to the crash. As I did that I happened to notice that it looked like an object was becoming null that shouldn't have been.

At this point, GDB with NSZombieEnabled and Instruments both reported NO zombies.

I added the NSLog-ing to the dealloc and release methods of the object I was having a problem with. Finally I was able to get enough sense to add a breakpoint in those methods and look at the stacktrace each time, when I found that release was being called by the autorelease pool.

I finally figured out that I wasn't retaining something that I should have been. Once I retained it, bingo, problem solved.

That said, the NSZombieEnabled and Instruments recommendations have both helped with some other bugs that have cropped up since then, so thanks everyone.