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.