Open Bug 2044428 Opened 2 months ago Updated 2 months ago

Crash in [@ mozilla::dom::workerinternals::loader::WorkerScriptLoader::EvaluateScript]

Categories

(Core :: DOM: Workers, defect, P3)

defect

Tracking

()

People

(Reporter: valentin, Unassigned)

References

Details

(Keywords: crash)

Crash Data

Crash report: https://crash-stats.mozilla.org/report/index/d75ec8da-0d16-47ec-abcd-8acc00260602

Reason:

SIGSEGV / SEGV_MAPERR

Top 10 frames:

0  libxul.so  mozilla::dom::workerinternals::loader::WorkerScriptLoader::EvaluateScript(JSC...  dom/workers/ScriptLoader.cpp:1301
0  libxul.so  mozilla::dom::workerinternals::loader::WorkerScriptLoader::ProcessPendingRequ...  dom/workers/ScriptLoader.cpp:882
1  libxul.so  mozilla::dom::workerinternals::loader::ScriptExecutorRunnable::ProcessClassic...  dom/workers/ScriptLoader.cpp:1778
1  libxul.so  mozilla::dom::workerinternals::loader::ScriptExecutorRunnable::WorkerRun(JSCo...  dom/workers/ScriptLoader.cpp:1798
2  libxul.so  mozilla::dom::WorkerThreadRunnable::Run()  dom/workers/WorkerRunnable.cpp:438
3  libxul.so  nsThread::ProcessNextEvent(bool, bool*)  xpcom/threads/nsThread.cpp:1173
3  libxul.so  NS_ProcessNextEvent(nsIThread*, bool)  xpcom/threads/nsThreadUtils.cpp:472
4  libxul.so  mozilla::dom::WorkerPrivate::RunCurrentSyncLoop()  dom/workers/WorkerPrivate.cpp:5422
5  libxul.so  mozilla::dom::AutoSyncLoopHolder::Run()  dom/workers/WorkerPrivate.cpp:6972
5  libxul.so  mozilla::dom::workerinternals::(anonymous namespace)::LoadAllScripts(mozilla:...  dom/workers/ScriptLoader.cpp:259

I was trying to reproduce bug 2022833 - I changed the UA string to Chrome using the User-Agent Switcher and Manager extension. Refreshed the page - iframe crashed.

Hm, that crash report is somewhat broken ("[@ EMPTY: no frame data available; unknown error ]"), maybe because you were able to get the frames via a debugger? But it looks like https://crash-stats.mozilla.org/report/index/cf43e5d9-a022-4d23-beba-a55dd0260602 is you too and maybe that's the one you meant to link.

The line in question is on StrongWorkerRef::Private() which suggests an edge case related to the worker being torn down will trying to load things. Note that the specific line in question is checking whether we're a ServiceWorker, and that's absolutely going to be false in the case of this process (which is notably COOP+COEP), so we shouldn't be in line 1302[1]. The COOP+COEP thing could be interesting in terms of ORB possibly getting involved and potentially in a way that might trigger multiple consecutive errors that might possibly do something interesting. But in general the script loader waits until it's processed/given up for all scripts before tearing things down, so the situation is generally surprising (but believable).

1: And note that I briefly threw claude directly at the crash report and it got fixated on line 1302, ignoring line 1301, then hallucinated some claims about the tree it was looking at being out of sync (it's not), so do be careful

Severity: -- → S3
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.