678174 - Stack scanning being used on Linux tinderbox crashes

Status: NEW

(Toolkit :: Crash Reporting, defect)

Description

[Jeff Muizelaar [:jrmuizel]]

I ran into the following crash and noticed that the stack wasn't great. 
http://tinderbox.mozilla.org/showlog.cgi?log=Mozilla-Inbound/1313023027.1313025329.11041.gz&fulltext=1#err1

Shouldn't we be using CFI here instead of stack scanning?

Comment 1

[(not currently active) Ted Mielczarek]

I see what's going wrong.

The top two frames look like:
Thread 0 (crashed)
 0  libpthread-2.11.so + 0xee6b
    rbx = 0x000000d5   r12 = 0xe0202490   r13 = 0xdf26c160   r14 = 0x010280f0
    r15 = 0x0102b860   rip = 0xd360ee6b   rsp = 0x84d6ec78   rbp = 0x84d6ec80
    Found by: given as instruction pointer in context
 1  libxul.so!CrashInJS [jsutil.cpp:17fa5a741f84 : 95 + 0x9]
    rip = 0xe0e87896   rsp = 0x84d6ec80
    Found by: stack scanning

(the register values are truncated to 32-bits, that's fixed in Breakpad FWIW)

The symbol data for CrashInJS looks like:
FUNC 2536888 10 0 CrashInJS
2536888 4 72 4403
253688c a 95 4403
2536896 2 97 4403

STACK CFI INIT 2536888 10 .cfa: $rsp 8 + .ra: .cfa -8 + ^
STACK CFI 2536889 $rbp: .cfa -16 + ^ .cfa: $rsp 16 +
STACK CFI 253688c .cfa: $rbp 16 +
STACK CFI 2536897 .cfa: $rsp 8 +

The rva for frame 1 is 0x2536896, so we're in the third line of the CFI rules, which says that .cfa is based on rbp. Since we got to frame 1 from frame 0 via stack scanning, we didn't recover rbp, so we can't use the CFI rules to unwind.

I guess it's using rbp here because this is a debug build, so it's using a frame pointer? I think there are two ways to fix this:
1) fix bug 528231, which is feasible now that we're fixing bug 561754
2) Make the amd64 stackwalker able to recover rbp when stack scanning. The x86 stackwalker attempts to recover ebp:
http://code.google.com/p/google-breakpad/source/browse/trunk/src/processor/stackwalker_x86.cc#497