Bug 1299581 explains a problem we ran into over in sandboxing-land, and bug 1310116 is a new instance of it that just got filed: given a Firefox build with frame pointers (e.g., a Nightly) and system libraries without frame pointers (this is almost always the case) a crash in the system libraries which hasn't overwritten the frame pointer register will lose the innermost frame from Firefox. In constrast, if there were no frame pointers and Breakpad had to do stack scanning, it would (probably) find that frame. For example, in this case: _pt_root (in libpthread) calls WaitPidDaemonThread (in NSPR) which calls waitpid (in libc/libpthread) which crashes; what we want is the call site in WaitPidDaemonThread, but what we get is a bug titled “Crash in _pt_root”. Caveats: this use case probably isn't common, and if we can do client-side stack walking (bug 1280469) and use a precise EH-based unwinder then none of this will matter.

This is indeed unfortunate, and I don't have a good solution. Minidumps in general are designed for a system where you have frame pointers everywhere, or at least can be relatively assured that you have frame pointers for system libraries. On Win64 Microsoft makes system DLLs available via their symbol server, so the equivalent situation there tends to work OK because you can get the EH info from the system DLLs. It would be good to make sure that our client side stackwalking work does the right thing on 64-bit Linux. There's special code there to handle Win64, but not Linux.

This can also happen in non-sandbox-related cases: e.g., bug 1509813, where we passed a null pointer to strcmp and lost the frame that would have told us which strcmp call it was.