I’ll go ahead and admit that I’m not keen on using GDB, even with Xcode’s built-in support. I needed to get familiar with it recently, however, because of a crashing bug I just squashed in Share. My problem was that my server was creating NSFileHandles that might hang around even after the server was released. As a result, a rogue NSFileHandle (running in an Apple-produced thread) would try to message a nil object and crash. Since the file handle was reading in the background, it would pop up intermittently. I needed robust debugging support.

I was aware of the (under-documented) NSZombieEnabled so I figured I’d start there. The extended entry details how to turn on NSZombieEnabled and configure a GDB breakpoint.

How it works

NSZombieEnabled is a bit of magic worker when it comes to debugging memory issues. When it is turned on, objects aren’t actually released to the big autorelease pool in the sky. Instead, they are replaced with a zombie version of the object. Whenever that zombie object gets called, it throws a wrench and logs what was called.

On some occasions, GDB will give cryptic stack traces when an app crashes due to memory issues. NSZombieEnabled gives you precise information on what went wrong and stops the stack right where you need it. For dealing with intermittent memory-based crashes, there isn’t a better tool.

How to do it

1. NSZombieEnabled is an environment variable. Double-click your application under Xcode’s “Executables” item.

   

2. Add a new variable to the environment called “NSZombieEnabled” with the value “YES”.

   

3. Now, you’ll receive better debugging information in the Console Log whenever an invalid object is messaged. You can get even better information from GDB by setting a breakpoint. Open the breakpoints from Xcode’s “Debug” menu.

   

4. Add a new breakpoint by double-clicking on the “Double-Click for Symbol” and enter “-[_NSZombie methodSignatureForSelector:]”.

   

Time to crash

Now when your application crashes, the Run Log will explain what crashed and the debugger will contain a useful stack. Note that you’ll have to use stuff like “Build and Debug” to use your breakpoints (instead of “Build and Run”). Also, you should turn off NSZombieEnabled when releasing your application. Otherwise, you’ll have massive memory leaks because nothing will be truly released.