Bug 1849269 Comment 1 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

Looks as if [`mRemoteWorkerController`]https://searchfox.org/mozilla-central/rev/d7a8eadc28298c31381119cbf25c8ba14b8712b3/dom/workers/sharedworkers/SharedWorkerManager.cpp#162) is `nullptr` ?

We clear it only on `Terminate`, AFAICS. There is the theoretical possibility to end without [if we fail to allocate it](https://searchfox.org/mozilla-central/rev/d7a8eadc28298c31381119cbf25c8ba14b8712b3/dom/workers/remoteworkers/RemoteWorkerController.cpp#42-43,48,51) but that allocation should be infallible and thus crash on OOM, IIUC.

The [lambda dispatched as runnable](https://searchfox.org/mozilla-central/rev/d7a8eadc28298c31381119cbf25c8ba14b8712b3/dom/workers/sharedworkers/SharedWorkerManager.cpp#308,312) captures a `RefPtr` to the containing `SharedWorkerManager`, keeping it alive, but we could end up with `mRemoteWorkerController == nullptr` at the second dispatch of this runnable, if that was possible. We could add a diagnostic assert before dispatching to see, if that happens and who is causing this.
Looks as if [`mRemoteWorkerController`](https://searchfox.org/mozilla-central/rev/d7a8eadc28298c31381119cbf25c8ba14b8712b3/dom/workers/sharedworkers/SharedWorkerManager.cpp#162) is `nullptr` ?

We clear it only on `Terminate`, AFAICS. There is the theoretical possibility to end without [if we fail to allocate it](https://searchfox.org/mozilla-central/rev/d7a8eadc28298c31381119cbf25c8ba14b8712b3/dom/workers/remoteworkers/RemoteWorkerController.cpp#42-43,48,51) but that allocation should be infallible and thus crash on OOM, IIUC.

The [lambda dispatched as runnable](https://searchfox.org/mozilla-central/rev/d7a8eadc28298c31381119cbf25c8ba14b8712b3/dom/workers/sharedworkers/SharedWorkerManager.cpp#308,312) captures a `RefPtr` to the containing `SharedWorkerManager`, keeping it alive, but we could end up with `mRemoteWorkerController == nullptr` at the second dispatch of this runnable, if that was possible. We could add a diagnostic assert before dispatching to see, if that happens and who is causing this.

Back to Bug 1849269 Comment 1