Crashes in objc_msgSend() (and leaf functions) miss its caller in the stack trace

[GoogleCodeExporter]

A crash in objc_msgSend() does not include its caller in the stack trace, 
leading to confusing crash reports. This is probably because objc_msgSend does 
not set up a stack frame.

The crash report from ReportCrash does, presumably because it disassembles the 
binary to figure out what's going on.

The desired address is in r14 (LR) on ARM, LR on PowerPC, and some offset off 
sp on x86 (I forget if objc_msgSend moves the stack pointer; leaf functions 
certainly might). While it is possible to manually turn LR into a symbol name, 
it's a bit tedious and it doesn't work for x86 (it looks like x86 crash reports 
don't dump the stack, even with ReportCrash).

I'm not sure how to approach this — figuring out if you're in a leaf-function 
is non-trivial and really not something you want to do in a crashing process. A 
fudgy solution is to add a pseudo-stackframe between 0 and 1 for the crashing 
thread with the address in LR or whatever SP points to on x86, pending some 
investigation into what objc_msgSend does on x86.

(And now I get to write a script to sift through crash reports, looking for 
objc_msgSend.)

Original issue reported on code.google.com by tc...@airsource.co.uk on 28 Sep 2011 at 7:54

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

This should be high priority.  I am running iOS 5.0.1.

I noticed an issue with Crittercism where the stack trace was missing a line 
that the device crash log did have (the line pointing to my code).  I then 
tried QuincyKit and had exactly the same problem.  I then found a sample app 
which traps fatal signals and calls backtrace/backtrace_symbols and that did 
NOT have the problem.  I then found this issue.

Please fix this asap.  The problem here makes Crittercism, QuincyKit, et al 
worthless to me as it won't tell me the location where an over-released ivar 
was accessed.

Regards, Patrick

Original comment by patrickj...@gmail.com on 19 Feb 2012 at 4:43

[GoogleCodeExporter]

The built-in crash reporter has the advantage of being in a separate process, 
so it can do a lot of things which really aren't appropriate for an in-process 
crash reporter. In this case, I believe it inspects the code to (try to) 
determine if it's in prologue/epilogue instead of naively walking up the stack.

It looks like both PLCrashReporter and backtrace() do different "wrong" things: 
backtrace() outputs a line for objc_msgSend()'s *caller*, but not for 
objc_msgSend(). If you do something like
  void foo() { NSLog(@"%p", *(void**)1); }
backtrace() seems to output foo's caller twice. Weird, right?

At the very least, it looks like backtrace() isn't designed to be signal-safe. 
backtrace_symbols() really isn't signal-safe, since it calls malloc(). 
backtrace_symbols_fd() seems to do something weird inside a signal handler (it 
seems to miss out random lines with fd=1 or fd=2, whereas calling 
backtrace_symbols() and write() directly seems to "work"). And at the end of 
the day, backtrace() isn't the right tool for the job, outputting lines for 
fatal_signal_handler() and _sigtramp().

All that said, PLCrashReporter is not "worthless" on ARM/PPC:
1. Grab LR from the crash report.
2. Look through the Binary Images section to find out which image it's in and 
the load address.
3. Do something like "atos -arch armv7 -o $unstripped_image -l $load_address 
$address_in_lr" (assuming the device uses armv7).

This should not be too hard to do with some tweaks to symbolicatecrash, 
provided you're good at picking apart Perl code.

Original comment by tc...@airsource.co.uk on 20 Feb 2012 at 4:06

[GoogleCodeExporter]

Hi, thanks for the tip on the LR register.  That works when I *have* the LR 
register.  QuincyKit shows you the registers, Crittercism does not.  I realize 
that's not a PLCrashReporter issue, but it does limit the usability of some of 
these products.

Regards, Patrick

Original comment by patrickj...@gmail.com on 20 Feb 2012 at 9:32

[GoogleCodeExporter]

Original comment by landon.j.fuller@gmail.com on 1 Jan 2013 at 7:52

• Changed state: Accepted
• Added labels: Type-Enhancement
• Removed labels: Type-Defect