522788 - In crash reports for instructions that deref a bad address, we should display the bad address

Status: RESOLVED FIXED

(Toolkit :: Crash Reporting, defect)

Description

[Daniel Holbert [:dholbert]]

In this crash report...
http://crash-stats.mozilla.com/report/index/644fa8eb-fcb6-4464-8eb5-95e6e2091016
...the displayed crash reason is:
 Crash Reason	SIGSEGV
 Crash Address	0xee56c4

I happened to catch this crash in GDB before submitting the crash report, and it turned out that 0xee56c4 is actually a mov instruction that dereferences a bad address.

"disas $pc" shows:
  0x00ee56c4: mov    (%ecx),%eax
and "info registers" shows:
  ecx            0xf0dea7ff 

So, we're crashing because we trying to dereference the address "0xf0dea7ff".  That's the "interesting" address in this crash, not the address of the instruction.  However, that information isn't captured at all in the crash report.

Can we get this information shown in breakpad somehow?

Comment 1

[Daniel Holbert [:dholbert]]

bz tells me that on Windows this already works.  i.e. crash reports list the failing data address on Windows (as desired), but they list the failing instruction address on Linux.

Comment 2

[Zack Weinberg (:zwol)]

In principle it is very easy to get the faulting data address on all Unix-like systems we care about:  register all the signal handlers with SA_SIGINFO, their signature becomes 

void action(int signo, siginfo_t *info, void *ctxt)

and info->si_addr is the address we want.  This also allows us to eliminate the inline assembly and stack-walking that the linux (and solaris? it's not clear) version of exception_handler.cc does to get the sigcontext structure -- it's right there in the 'ctxt' argument.

Comment 3

[Zack Weinberg (:zwol)]

Note that as a consumer of crash information I kinda want *both* the address of the failed memory reference, and the address of the instruction.  That might be in the stack trace, though.  In a raw dump line, e.g. 

0|0|libxul.so|nsFrameManager::RemoveFrame(nsIFrame*, nsIAtom*, nsIFrame*)|hg:hg.mozilla.org/mozilla-central:layout/base/nsFrameManager.cpp:382c73f2650f|736|0x6

what do the last two numbers (|736|0x6) mean?

Comment 4

[(not currently active) Ted Mielczarek]

It's possible that this is already fixed upstream, there's a Linux client rewrite that landed that we haven't picked up yet. We already do the right thing for Windows and Mac here (I fixed the Mac one myself).

The last two numbers in that line are the source line number, and the instruction offset from the beginning of that line. We don't expose the raw instruction pointer value (unless that frame isn't in a loaded module), although Breakpad clearly knows it.

Comment 5

[Zack Weinberg (:zwol)]

Instruction offset from the beginning of the line is cute, but instruction offset from the beginning of the *function* would be significantly more useful to me.

Comment 6

[(not currently active) Ted Mielczarek]

Will be fixed with bug 514188.

Comment 7

[(not currently active) Ted Mielczarek]

Should be able to verify with today's nightly.