Closed
Bug 1044483
Opened 10 years ago
Closed 10 years ago
Crash in ThreadStackHelper::FillStackBuffer
Categories
(Core :: Gecko Profiler, defect)
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.
I suspect this is an rr bug.
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.
Description
•