EXC_BAD_ACCESS during startup

Once again, the XCODE debugger not only failed to help but got in the way by showing me a stack trace that was not directly relevant to my problem.   The program crashed with EXC_BAD_ACCESS and the stack trace looked like this:

#0    0×90a594c7 in objc_msgSend
#1    0xbffff7b8 in ??
#2    0×932899d8 in loadNib
#3    0×932893d9 in +[NSBundle(NSNibLoading) _loadNibFile:nameTable:withZone:ownerBundle:]
#4    0×9328903a in +[NSBundle(NSNibLoading) loadNibFile:externalNameTable:withZone:]
#5    0×93288f7c in +[NSBundle(NSNibLoading) loadNibNamed:owner:]
#6    0×93288cc3 in NSApplicationMain
#7    0×00009f80 in main at main.mm:17

This made me think that my NIB was corrupt since I didn’t see anything in the stack trace that pointed to my code. After wasting several hours investigating that rat hole, I decided to try to do what the debugger didn’t help with and that’s track down the offending line.  With breakpoints and Debugger(); calls (breakpoints don’t always work for me) I found that an IBOutlet was not being initialized and I was sending a message to nil.  If the run-time was not going to flag this as an error, why would this cause a problem down the line?  Arrggg! 

Lesson learned, if a stack trace looks similar to the above, then look at your initialization code of your Nib objects.

Memory bugs in Cocoa

At work, our software runs on Windows and Mac OS.  I’m trying to reuse as much code as possible; not through some fancy cross-platform tools but by simply writing in portable C or C++ code and by using class wrappers that can each be implemented in the native platform.  One thing I’ve been pretty pleased with XCode is it’s support of mixing Objective-C and C++ code fairly seamlessly.

Recently, in trying to port some C++ Windows code over I started having some memory crashes.  Unfortunately the XCode debugger was of very little help with the stack trace not including any calls from my code.  This was an excellent thread on some techniques to troubleshoot EXC_BAD_ACCESS problems.  Fortunately, I didn’t have to try all the various techniques listed.  After reading the entire thread I decided to pursue the notion that I might be over-releasing an object (though why should this be a problem?  A warning perhaps but seems once a reference counter is down to 0 calling release again should be harmless).  This DID lead me to the offending code so I was able to fix my problem without wasting too much time.  Once again, the developer community saved me hours if not days of debugging.  How did we get along as programmers before the Web?

Debugging AutoRelease problems