NSZombieEnabled is an environment variable which can be helpful to track down the elusive object causing the problem. With the environment variable set, Cocoa will redirect all objects isa pointer to an NZZombie object once an objects retain count has reached zero. In the future, should you try and send a message to a previously released object, an exception will be raised showing a message similar to the following:

Setting NSZombieEnabled Environment Variable

In the Groups and Files section, expand the Executables section and right click on your app name and choose Get Info from the dialog:

Select the Arguments tab on the top and then add a new entry in the Variables to be set in the environment section. Name the new variable to NSZombieEnabled and set its value to YES.

Tracking Down the Error

Using a zombie, messages sent to an object that has already released will now generate the exception shown above, and following the stack track should now help you find the location of the object that is generating the EXC_BAD_ACCESS error.

Don’t forget to remove the environment variable, or at a minimum untick the checkbox once you find the source of the problem.

Since that time I’ve pulled together a few more macros that I use on a regular basis for printing debug information on rectangles, points and sizes. I’ve also included a means to turn debug information on/off so debug statements are not included in builds targeted as final releases.

//~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  
// Debug
//~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#define DEBUG_ON  // Toggle to DEBUG_OFF to hide all debug code 
 
#ifdef DEBUG_ON
  #define debug(format, ...) CFShow([NSString stringWithFormat:format, ## __VA_ARGS__]);
#else
  #define debug(format, ...) 
#endif
 
#define debugRect(rect) debug(@"%s x:%.4f, y:%.4f, w:%.4f, h%.4f", #rect,
    rect.origin.x, rect.origin.y, rect.size.width, rect.size.height)
#define debugSize(size) debug(@"%s w:%.4f, h:%.4f", #size, size.width, size.height)
#define debugPoint(point) debug(@"%s x:%.4f, y:%.4f", #pt, pt.x, pt.y)

At some point, capturing debug statements to a file (versus the console) can be helpful to track down bugs. The good news is that you can continue to use NSLog (and/or the debug command from the previous post) by simply making a change to where stderr is directed.

For example, to re-direct stderr to a file “debug.txt” off the root of the system drive, follow these steps:

// Create OS specific path
const char *path = [@"/debug.txt" fileSystemRepresentation];
 
// Specify stderr writes to a file (truncating contents first) 
freopen(path, "w", stderr);

Each time you run your application, the contents of the file “debug.txt” will be truncated and all output written to the file. If you would like to keep a running tally of debug output across invocations of the application, you can change ‘freopen’ to append contents as follows:

// Specify stderr appends to a file
freopen(path, "a", stderr);

As an alternative, one can craft a macro that uses CFShow, which outputs Core Foundation objects to stderr. CFShow uses callbacks to objects to display their descriptions, which allows one to use “%@” like you would when calling NSLog.

I often include the following debug definition as part of my projects:

#define debug(format, ...) CFShow([NSString stringWithFormat:format, ## __VA_ARGS__]);

A few short examples follow showing the difference in output between NSLog and the debug macro shown above.

1
2
3
4
5
6
7
8
9
10
11
12

struct point
{
  int x;
  int y;
};
typedef struct point POINT;
 
POINT topLeft;
topLeft.x = 15, topLeft.y = 20;
 
NSLog(@"x: %d y: %d", topLeft.x, topLeft.y);
debug(@"x: %d y: %d", topLeft.x, topLeft.y);

The output will now look as follows:

Here’s another example, this time passing in an object:

1
2
3
4
5
6
7
8
9
10

NSDate *today = [NSDate date];
NSDateFormatter *dateFormat = [[NSDateFormatter alloc] init];
[dateFormat setDateFormat:@"EEEE MMMM d, YYYY"];
NSString *dateString = [dateFormat stringFromDate:today];
[dateFormat release];
 
...
 
NSLog(@"Date: %@", dateString);
debug(@"Date: %@", dateString);

And the corresponding output:

Ahhh, much better.