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 0x90a594c7 in objc_msgSend
#1 0xbffff7b8 in ??
#2 0x932899d8 in loadNib
#3 0x932893d9 in +[NSBundle(NSNibLoading) _loadNibFile:nameTable:withZone:ownerBundle:]
#4 0x9328903a in +[NSBundle(NSNibLoading) loadNibFile:externalNameTable:withZone:]
#5 0x93288f7c in +[NSBundle(NSNibLoading) loadNibNamed:owner:]
#6 0x93288cc3 in NSApplicationMain
#7 0x00009f80 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.