Open Bug 678174 Opened 13 years ago Updated 2 years ago

Stack scanning being used on Linux tinderbox crashes

Categories

(Toolkit :: Crash Reporting, defect)

x86
macOS
defect

Tracking

()

People

(Reporter: jrmuizel, Unassigned)

Details

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?
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
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.