1694492 - Crash in [@ profiler_suspend_and_sample_thread]

Status: RESOLVED WORKSFORME

(Core :: Gecko Profiler, defect, P2)

Description

[Emilio Cobos Álvarez (:emilio)]

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 

Comment 1

[Gerald Squelart (he/him) (not at Mozilla since 2022-09-15)]

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...

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

Closing because no crashes reported for 12 weeks.

Comment 3

[Gerald Squelart (he/him) (not at Mozilla since 2022-09-15)]

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.