Crash in [@ mozilla::dom::WorkerPrivate::RunLoopNeverRan]
Categories
(Core :: DOM: Workers, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr102 | --- | unaffected |
firefox-esr115 | --- | unaffected |
firefox115 | --- | unaffected |
firefox116 | + | fixed |
firefox117 | --- | fixed |
People
(Reporter: diannaS, Assigned: edenchuang)
References
(Regression)
Details
(Keywords: crash, regression, topcrash)
Crash Data
Attachments
(1 file)
48 bytes,
text/x-phabricator-request
|
RyanVM
:
approval-mozilla-beta+
|
Details | Review |
Crash report: https://crash-stats.mozilla.org/report/index/820913b3-30d2-4236-8332-0f7b00230610
MOZ_CRASH Reason: MOZ_DIAGNOSTIC_ASSERT(!HasActiveWorkerRefs())
Top 10 frames of crashing thread:
0 xul.dll mozilla::dom::WorkerPrivate::RunLoopNeverRan dom/workers/WorkerPrivate.cpp:3141
1 xul.dll mozilla::dom::workerinternals:: const dom/workers/RuntimeService.cpp:2088
1 xul.dll mozilla::ScopeExit<`lambda at /builds/worker/checkouts/gecko/dom/workers/RuntimeService.cpp:2083:41'>::~ScopeExit mfbt/ScopeExit.h:106
1 xul.dll mozilla::dom::workerinternals:: dom/workers/RuntimeService.cpp:2229
2 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1193
3 xul.dll NS_ProcessNextEvent xpcom/threads/nsThreadUtils.cpp:479
3 xul.dll mozilla::ipc::MessagePumpForNonMainThreads::Run ipc/glue/MessagePump.cpp:300
4 xul.dll MessageLoop::RunInternal ipc/chromium/src/base/message_loop.cc:370
4 xul.dll MessageLoop::RunHandler ipc/chromium/src/base/message_loop.cc:363
5 xul.dll MessageLoop::Run ipc/chromium/src/base/message_loop.cc:345
Reporter | ||
Comment 1•2 years ago
|
||
:nika could this have been caused by bug 1826206?
Comment 2•2 years ago
|
||
(In reply to Dianna Smith [:diannaS] from comment #1)
:nika could this have been caused by bug 1826206?
I can't think of any way that this could be being caused by that bug. The change there was largely just a signature change for a function, and the introduction of some TaskQueues in a way which doesn't impact worker threads at all.
The RunLoopNeverRan
function in the stack is only run if we fail very early when starting up a worker thread (https://searchfox.org/mozilla-central/rev/b91e9bef5a6d6f7b549fbc9cba70cb4665ed3866/dom/workers/RuntimeService.cpp#2083-2089,2107,2122,2128,2131), so presumably we're hitting one of the error cases there. I'm guessing it's a failure starting the JSContext? I don't think we'll end up failing to create a BackgroundChild
unless we're in shutdown, and it doesn't appear that we are (though the full main-thread stack is missing so it's hard to say for sure).
Redirecting to someone more familiar with the worker thread lifecycle.
Updated•2 years ago
|
Comment 3•2 years ago
|
||
The bug is linked to a topcrash signature, which matches the following criterion:
- Top 10 desktop browser crashes on nightly
For more information, please visit BugBot documentation.
Reporter | ||
Updated•2 years ago
|
Reporter | ||
Updated•2 years ago
|
Comment 4•2 years ago
|
||
The bug is marked as tracked for firefox116 (beta). However, the bug still isn't assigned.
:jstutte, could you please find an assignee for this tracked bug? If you disagree with the tracking decision, please talk with the release managers.
For more information, please visit BugBot documentation.
Assignee | ||
Updated•2 years ago
|
Assignee | ||
Comment 5•2 years ago
|
||
Comment 6•2 years ago
|
||
(This is a regression from a change made in https://phabricator.services.mozilla.com/D177511 on bug 1800659.)
Comment 7•2 years ago
|
||
Set release status flags based on info from the regressing bug 1800659
Assignee | ||
Comment 9•2 years ago
|
||
Comment on attachment 9342913 [details]
Bug 1837856 - Notify WeakWorkerRefs in WorkerPrivate::RunLoopNeverRan. r=asuth
Beta/Release Uplift Approval Request
- User impact if declined: Users would get into MOZ_CRASH easily.
- Is this code covered by automated tests?: No
- Has the fix been verified in Nightly?: No
- Needs manual test from QE?: No
- If yes, steps to reproduce:
- List of other uplifts needed: None
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): Low risk since we just fallback the behavior to Fx115.
- String changes made/needed:
- Is Android affected?: Yes
Updated•2 years ago
|
Comment 10•2 years ago
|
||
bugherder |
Comment 11•2 years ago
|
||
Comment on attachment 9342913 [details]
Bug 1837856 - Notify WeakWorkerRefs in WorkerPrivate::RunLoopNeverRan. r=asuth
Approved for 116.0b5.
Comment 12•2 years ago
|
||
uplift |
Updated•2 years ago
|
Description
•