iphone - How to read objective-c stack traces

Question

i have the following stack trace:

0 MyApp 0x000833a3 +[TFCrashHandler backtrace] + 26
1 MyApp 0x000836bd TFSignalHandler + 28
2 libsystem_c.dylib 0x33eac727 _sigtramp + 34
3 ??? 0x00000002 0x0 + 2
4 MyApp 0x000803f1 msgpack_unpack_next + 112
5 MyApp 0x0007faeb +[MessagePackParser parseData:] + 74
6 MyApp 0x0007f84b -[NSData(NSData_MessagePack) messagePackParse] + 26
7 MyApp 0x000254c3 +[Http get:params:cacheMins:msgPack:complete:] + 146
...

And i'm wondering how to read it:

• I assume i go from the bottom up, eg line 7 called line 6 called line 5, etc.
• What does the '+ 112' on line 4 mean? Is that a line number in the code file where it crashed?
• What does the '???' on line 3 mean?

Thanks a lot

Answer 1

0 MyApp 0x000833a3 +[TFCrashHandler backtrace] + 26

Crash was generated from +[TFCrashHandler backtrace] + 26; from whatever instruction fell at that symbol location + 26 bytes.

If that is really the bottom of your stack trace and it crashed there, then the TCrashHandler is obscuring the real crash. The real crash looks to be a couple of frames above.

1 MyApp 0x000836bd TFSignalHandler + 28

TFSignalHandler was what called +backtrace.

2 libsystem_c.dylib 0x33eac727 _sigtramp + 34

Ewww... a signal trampoline. The app received a signal and the a trampoline was set to call TFSignalHandler().

There are situations where a signal handler might be called on a random thread. I.e. there is a minuscule chance that this particular crash had nothing to do with the parser and everything to do with a crash somewhere else. However, without knowing more about the parser, I'd question whether it is hardened against malicious input (which could certainly cause a crash like this).

3 ??? 0x00000002 0x0 + 2

Stack was undecodable. Ignore. Meaningless. Best case; fallout from compiler optimization. Worst case; somebody pooped on the stack and the backtrace mechanism can't figure out what is going on (highly unlikely -- usually, stack poop splatters to the point of preventing a full backtrace).

4 MyApp 0x000803f1 msgpack_unpack_next + 112

Ooooh... trickzy. Someone is using C to parse stuff. And it crashed. Whatever instruction was 112 bytes from the entry point to the function went boom. But, not really, because it called the signal handler and was handled by that; which is still a boom but the signal handler has effectively destroyed additional forensic evidence.

The "trickzy" comment references that an optimizing compiler against a big pile o' C can end up collapsing frames to the point that the crash could have happened in a function well below this one.

5 MyApp 0x0007faeb +[MessagePackParser parseData:] + 74

MessagePackParser was parsing when things went horribly wrong.

6 MyApp 0x0007f84b -[NSData(NSData_MessagePack) messagePackParse] + 26
7 MyApp 0x000254c3 +[Http get:params:cacheMins:msgPack:complete:] + 146

Ahh... yes.... somebody done grabbed some data from HTTP and it was malformed, causing the crash.

Bottom line; the parser got bogus input and crashed. There was a signal handler in place that tried to help by creating a backtrace, but -- apparently -- didn't really reveal any more info. A long shot alternative is that the signal was generated somewhere else and this thread was randomly selected to handle it -- if you can consistently recreate this crash, the random-thread-signal case is unlikely.

Unless you have a capture of the input data or can somehow guess how msgpack_unpack_next() might crash, you are out of luck without providing more info.