EXC_BAD_ACCESS at UIApplicationMain - how to interpret this backtrace?

#0  0x0149609b in objc_msgSend ()
#1  0x06a75960 in ?? ()
#2  0x0108df9a in _performRunLoopAction ()
#3  0x0131189b in __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ ()
#4  0x012a66e7 in __CFRunLoopDoObservers ()
#5  0x0126f1d7 in __CFRunLoopRun ()
#6  0x0126e840 in CFRunLoopRunSpecific ()
#7  0x0126e761 in CFRunLoopRunInMode ()
#8  0x01c871c4 in GSEventRunModal ()
#9  0x01c87289 in GSEventRun ()
#10 0x00393c93 in UIApplicationMain ()
#11 0x00001f68 in main (argc=1, argv=0xbffff028) at /Users/Stu/Documents...

I'm a little confused by the ?? () near the top. On seeing that this error appeared at the line int retVal = UIApplicationMain(argc, argv, nil, nil); I assumed a memory access problem to do with the autorelease pool, but I haven't found any so far.

The error happens when I call for a CoreData object with a certain property to be deleted. This process takes an NSDate object, finds the core data object with that dat开发者_JS百科e as its 'timestamp', and deletes that object.

I have NSZombie enabled along with NSDebug and MallocStackLogging, however no info is shown in the log (other than the backtrace when I request it of course). Stepping through the code doesn't help narrow down the problem either.

---

Problem solved.

As I originally speculated, it was indeed to do with the autorelease pool (always trust your instinct...). For some bizarre reason - probably after not sleeping for 36 hours - I had autoreleased an object that had no business being autoreleased. It was just a simple custom getter-style method that returns a text object that is currently selected.

Not sure why an NSZombie wasn't created for it though...

---

objc_msgSend() causing EXC_BAD_ACCESS usually means that a function is not implemented in the target object. We can also see that an Observer callback is being made. I would venture to guess that you somewhere called -addObserver:selector:name:object: with the wrong selector. (this is usually printed just before the stack trace).