Closed Bug 1044483 Opened 10 years ago Closed 10 years ago

Crash in ThreadStackHelper::FillStackBuffer

Categories

(Core :: Gecko Profiler, defect)

x86_64
Linux
defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: cjones, Unassigned)

Details

(Whiteboard: [rr])

The crash is a null deref of mStackToFill Program received signal SIGSEGV, Segmentation fault. mozilla::ThreadStackHelper::FillStackBuffer (this=0xffff8658) at /home/cjones/rr/mozilla-central/xpcom/threads/ThreadStackHelper.cpp:286 286 size_t reservedBufferSize = mStackToFill->AvailableBufferSize(); (gdb) bt #0 mozilla::ThreadStackHelper::FillStackBuffer (this=0xffff8658) at /home/cjones/rr/mozilla-central/xpcom/threads/ThreadStackHelper.cpp:286 #1 0x5612021e in mozilla::ThreadStackHelper::FillStackHandler (aSignal=38, aInfo=0xffff85cc, aContext=0xffff864c) at /home/cjones/rr/mozilla-central/xpcom/threads/ThreadStackHelper.cpp:174 #2 <signal handler called> ... We hit this after receiving a RT signal 38, which I guess is the new profiler signal? This seems to be around shutdown time, but I'm not entirely sure. I can reproduce this 100% when recording the layout/generic mochitests under rr, but it doesn't seem to happen when I run the tests outside of rr. Happy to answer gdb queries for anyone interested in debugging this.
This isn't the profiler. These signals are being sent by the BackgroundHangManager.
Yeah.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.