Nat! bio photo


Senior Mull

Twitter Github Twitch

EXC_BAD_ACCESS and no stack trace == more quality time lost in Xcode


And as things are wont to do, Xcode debugging just went from bad to worse for me. To figure out some other problems (see previous posts) I enabled some debug code, which led to this crasher in middle of nowhere^h^h^h^h^h^h^hobjc_msgSend. There is this tendency of debug code to create more bugs and henceforth more debug code, but I disgress...

With no clue in the console log and no stack trace (see picture) I was stumped.

Obviously the crash occurs at 0x986ceed7, where you see the red instruction pointer arrow.

Recovering the Stacktrace

You can help Xcode along a little ways to display the correct stack trace, and only god and apple know, why it can't do this on its own, but I guess syntax coloring is way more important...

Move the instruction pointer to a ret instruction. In the screenshot the address of a known ret instruction is marked green. If you see a different hexadecimal number in your disassembly there, by all means use that. Now go into the gdb debugger console to recover the stack trace:

(gdb) set $eip = 0x986cef35
(gdb) stepi
(gdb) where
#0  0x00000000 in ?? ()
#1  0x9842e5a4 in _NSDescriptionWithLocaleFunc ()
#2  0x92b04322 in _CFStringAppendFormatAndArgumentsAux ()
#3  0x92b036a9 in _CFStringCreateWithFormatAndArgumentsAux ()
#4  0x92babf2e in _CFLogvEx ()
#5  0x984bf7e8 in NSLogv ()
#6  0x984bf757 in NSLog ()

Voilà! Or Viola as it's commonly misspelled. Note, that I am almost always debugging with NSZombieEnabled on, so that is not a solution here.

Post a comment

All comments are held for moderation; basic HTML formatting accepted.

E-mail: (not published)