37

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

Chris
  • 39,719
  • 45
  • 189
  • 235
  • Does the '0x00000002' mean that the msgpack_unpack_next function jumped to a function at address '2', eg did an invalid function call somehow? – Chris Jun 24 '11 at 01:17
  • Nope; it is just a bogon stack frame likely as a result from compiler optimization. Best to ignore. – bbum Jun 24 '11 at 02:41

3 Answers3

63
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.

bbum
  • 162,346
  • 23
  • 271
  • 359
  • 1
    “Crash was generated from `+[TFCrashHandler backtrace]`…” Alternatively, the questioner is using a crash-log-reporting framework, TFCrashHandler is a class in the framework, and `+[TFCrashHandler backtrace]` is simply the method that generated this stack trace to send it to the questioner, and is present in its output only because it didn't exclude itself. – Peter Hosey Jun 24 '11 at 02:55
  • 1
    Yah; exactly. Sadly, all of which completely obscures the reason why the original crash happened. Give me registers and I can far better determine the reason of the crash. – bbum Jun 24 '11 at 03:02
  • 1
    Well, thanks for all your help, its very enlightening. Turns out it was a byte alignment issue in the msgpack_unpack_next function, which was easy enough to fix AFTER i spent forever trying to find where the problem was. – Chris Jun 26 '11 at 23:13
  • Oh, dangit! That unponderable stack frame is a sure fire indication of such an issue, sometimes anyway. – bbum Jun 27 '11 at 00:15
2

The '???' is something that can't be identified, probably code that was compiled without symbols, but could also be something else.

ThomasW
  • 16,981
  • 4
  • 79
  • 106
  • Would the hex address on that line "0x0...02" mean that the code jumped into address 2, eg called a function pointer set to '2'? – Chris Jun 24 '11 at 01:56
  • It looks like @bbum has addressed the question. When you have a choice between picking his answer and mine, pick his. – ThomasW Jun 24 '11 at 03:05
  • Incomplete. Should be a comment rather than an answer. – Max MacLeod Jul 13 '22 at 11:19
  • @MaxMacLeod when I wrote this answer I probably didn't have a high enough reputation to comment. – ThomasW Aug 01 '22 at 06:28
-2

Those are the line numbers in the implementation file. And the hex is the pointer in memory to the line call.

bdparrish
  • 3,216
  • 3
  • 37
  • 58
  • Does the '0x00000002' mean that the msgpack_unpack_next function jumped to a function at address '2', eg did an invalid function call somehow? – Chris Jun 24 '11 at 01:18
  • @Chris, something like that, this goes back to C programming, not sure exactly how Objective-C does it, but C, when it setup it's memory stack, the first few bits represent a null value, so if the hex value in front is the '0x00000002', then you can assume that it is a null value or undefined. – bdparrish Jun 24 '11 at 01:21
  • The line number don't seem to match up with runnable code. Eg line 74 in the MessagePackParser points to the @end line. Are you sure that's what it is? – Chris Jun 24 '11 at 01:25
  • 4
    Nope; not line numbers. Those are instruction offsets, no symbolication about it. – bbum Jun 24 '11 at 02:38