mikeash.com pyblog/friday-qa-2012-04-27-plcrashreporter-and-unwinding-the-stack-with-dwarf.html comments

Mark Aufflick - 2012-05-01 03:55:58

Tue, 01 May 2012 03:55:58 GMT

Wow this is exciting. None of my Mac apps ship via the app store not yet, but not having crash reporting has made me dread the app store. Not for much longer though - good work Gwynne and the always awesome HockeyApp guys!

Landon Fuller - 2012-04-27 19:57:43

Fri, 27 Apr 2012 19:57:43 GMT

Unfortunately upstream libunwind doesn't support Darwin, Mach-O, or the compact unwind encoding.

Apple has their own open-source implementation of a small subset of libunwind, but it's licensed under the APSL, and the version shipped with Mac OS X can't be used for our purposes without relying on private API and/or undefined semantics. Given the redistribution requirements around the APSL that could affect library users themselves, shipping our own customized version of Apple's minimal libunwind wasn't deemed workable.

Gwynne's work ultimately provides a standalone async-safe, C-based, MIT-licensed frame walking implementation.

Joe Groff - 2012-04-27 19:06:29

Fri, 27 Apr 2012 19:06:29 GMT

Good points, Landon. How about libunwind then? http://www.nongnu.org/libunwind/

Landon Fuller - 2012-04-27 16:15:39

Fri, 27 Apr 2012 16:15:39 GMT

Hey Joe --

Unfortunately neither of those are async-safe, can only be used on the current thread, and can hide information that is necessary in a crash reporter. I've written a bit more about the issues involved in crash reporting here:

http://landonf.bikemonkey.org/code/objc/Reliable_Crash_Reporting.20110912.html

Landon Fuller - 2012-04-27 16:13:30

Fri, 27 Apr 2012 16:13:30 GMT

Hi Chris --

There can be a measurable performance gain when making the extra register available, assuming that the compiler's heuristics for doing so aren't broken, and you're spending more time executing code that benefits from the register than you spend stack walking (usually a safe bet?).

If I recall correctly, certain GCC versions would *prefer* the callee-saved frame pointer over other callee-stompable registers when -fomit-frame-pointer was specified on x86. This lead to *less* efficient code, since it would have been more efficient to use a register that didn't require callee-preservation.

On x86-64, the ABI explicitly specifies that -fomit-frame-pointer semantics are the default, so it couldn't be relied on for crash reporting even if we wanted to.

Joe Groff - 2012-04-27 16:11:58

Fri, 27 Apr 2012 16:11:58 GMT

You can use the libc functions backtrack, backtrace_symbols, and backtrace_symbols_fd to get this same information.

Farcaller - 2012-04-27 14:43:45

Fri, 27 Apr 2012 14:43:45 GMT

It would be nice to see the same in corellation to arm binaries.

Chris - 2012-04-27 14:40:37

Fri, 27 Apr 2012 14:40:37 GMT

Wouldn't building with stack frame pointers be a lot easier? Is there a measurable performance reason why they're omitted in release builds?