Crash in [@ profiler_suspend_and_sample_thread]
Categories
(Core :: Gecko Profiler, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr78 | --- | unaffected |
firefox86 | --- | unaffected |
firefox87 | --- | affected |
firefox88 | --- | affected |
firefox89 | --- | ? |
People
(Reporter: emilio, Unassigned)
References
Details
(Keywords: crash, Whiteboard: [not-a-fission-bug])
Crash Data
Seems like we have a null registered thread in the profiler. Race condition? Though I don't know how it can happen from quick code inspection...
Maybe Fission related. (DOMFissionEnabled=1)
Crash report: https://crash-stats.mozilla.org/report/index/34cf25ec-059c-468c-a4f8-69cae0210222
Reason: SIGSEGV /0x00000080
Top 6 frames of crashing thread:
0 libxul.so profiler_suspend_and_sample_thread tools/profiler/core/platform.cpp:5888
1 libxul.so mozilla::ThreadStackHelper::GetStack toolkit/components/backgroundhangmonitor/ThreadStackHelper.cpp:145
2 libxul.so mozilla::BackgroundHangManager::MonitorThread toolkit/components/backgroundhangmonitor/BackgroundHangMonitor.cpp:79
3 libnspr4.so _pt_root nsprpub/pr/src/pthreads/ptthread.c:201
4 libpthread.so.0 start_thread nptl/nptl/pthread_create.c:473
5 libc.so.6 __GI___clone
Thank you Emilio for the report & bug.
The CorePS::RegisteredThreads()
Vector of UniquePtr's could only be accessed when the main profiler lock is held, so there "shouldn't" be a race there.
Maybe it was registered as null in the first place?
And in my experience crash reports' code location may not be exact, it could be another line nearby that's causing the bad read.
I'll need to have a closer look...
Updated•4 years ago
|
Comment 2•3 years ago
|
||
Closing because no crashes reported for 12 weeks.
Added note: The thread registration (and access to that data) is being rewritten in bug 1721939 and will start being used in bug 1722261, which hopefully should remove the possibility of incorrect accesses that could have explained the original issue.
Description
•