1895112 - Crash in [@ nsIGlobalObject::IsDying]

Status: NEW

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

Description

[Worcester12345]

Crash report: https://crash-stats.mozilla.org/report/index/1c885e6b-29af-4217-a354-3b9460240426

Reason: EXCEPTION_ACCESS_VIOLATION_READ

Top 10 frames:

0  xul.dll  nsIGlobalObject::IsDying() const  dom/base/nsIGlobalObject.h:103
0  xul.dll  mozilla::dom::ServiceWorkerOp::ServiceWorkerOpRunnable::WorkerRun(JSContext*,...  dom/serviceworkers/ServiceWorkerOp.cpp:296
1  xul.dll  mozilla::dom::WorkerRunnable::Run()  dom/workers/WorkerRunnable.cpp:342
2  xul.dll  nsThread::ProcessNextEvent(bool, bool*)  xpcom/threads/nsThread.cpp:1193
2  xul.dll  NS_ProcessNextEvent(nsIThread*, bool)  xpcom/threads/nsThreadUtils.cpp:480
3  xul.dll  mozilla::dom::WorkerPrivate::DoRunLoop(JSContext*)  dom/workers/WorkerPrivate.cpp:3341
4  xul.dll  mozilla::dom::workerinternals::(anonymous namespace)::WorkerThreadPrimaryRunn...  dom/workers/RuntimeService.cpp:2106
5  xul.dll  nsThread::ProcessNextEvent(bool, bool*)  xpcom/threads/nsThread.cpp:1193
5  xul.dll  NS_ProcessNextEvent(nsIThread*, bool)  xpcom/threads/nsThreadUtils.cpp:480
6  xul.dll  mozilla::ipc::MessagePumpForNonMainThreads::Run(base::MessagePump::Delegate*)  ipc/glue/MessagePump.cpp:300

Comment 2

[Andrew Sutherland [:asuth] (he/him)]

This is weird and maybe somewhat improbable; the stack says:

• The worker is in its normal steady state loop processing. We're not in the processing of shutting down the worker, and the initial CompileScriptRunnable has presumably run, because it is the first runnable that should always run.
• aWorkerPrivate->GlobalScope() would seem to have returned null. This is very hard to do since CompileScriptRunnable calls GetOrCreateGlobalScope at the very top, and it will return false if that fails, which should immediately advance the worker's state to closing (via its custom PostRun).

The most likely thing I could think of would be some kind of early return from WorkerThreadRunnable::Run that causes us to not actually enter CompileScriptRunnable::WorkerRun like when we check CancelBeforeWorkerScopeConstructed()) but I would still expect us to leave the worker steady state in that case.

cc'ing Eden but I think it probably makes sense to try and wait for the fuzzer or automation to provide some more context about what might be happening.