(In reply to Andrew McCreight [:mccr8] from comment #21) > I'm guessing that bug 1717657 is the LeakSanitizer manifestation of the same issue. That sounds very plausible. > My guess would be that a worker is trying to dispatch something to the main thread too late in shutdown, so it fails and we leak the runnable. The dispatch in question [is happening here](https://searchfox.org/mozilla-central/rev/684aefab97202faa982dd898f1d99208a46f12b0/dom/workers/remoteworkers/RemoteWorkerChild.cpp#559) in the callback of the `RemoteWorkerChild`'s `WeakWorkerRef`. IIUC the magic of `RemoteWorkerChild::InitializeOnWorker()` we are on the worker thread and - first take a [weak reference of our `RemoteWorkerChild`](https://searchfox.org/mozilla-central/rev/684aefab97202faa982dd898f1d99208a46f12b0/dom/workers/remoteworkers/RemoteWorkerChild.cpp#530) - we then create a `StrongWorkerRef` [that is supposed to keep the worker alive](https://searchfox.org/mozilla-central/rev/684aefab97202faa982dd898f1d99208a46f12b0/dom/workers/remoteworkers/RemoteWorkerChild.cpp#538-544) - we capture that `StrongWorkerRef` in the callback function of a new [`WeakWorkerRef`](https://searchfox.org/mozilla-central/rev/684aefab97202faa982dd898f1d99208a46f12b0/dom/workers/remoteworkers/RemoteWorkerChild.cpp#546-548) to ensure it will live until we receive the callback - once the worker ends, the callback function of the `WeakWorkerRef` will execute the [`NS_ProxyRelease` ](https://searchfox.org/mozilla-central/rev/684aefab97202faa982dd898f1d99208a46f12b0/dom/workers/remoteworkers/RemoteWorkerChild.cpp#559) which allocates the event that will be leaked What is not evident (to me) is: - who actually is the mOwningEventTarget (if it is the main thread as suspected by :mccr8 shouldn't it live longer than the worker?) and which [`Dispatch` function](https://searchfox.org/mozilla-central/search?q=symbol:_ZN14nsIEventTarget8DispatchE16already_AddRefedI11nsIRunnableEj&redirect=false) actually applies ? - what makes the dispatch apparently fail ?
Bug 1749068 Comment 22 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(In reply to Andrew McCreight [:mccr8] from comment #21) > I'm guessing that bug 1717657 is the LeakSanitizer manifestation of the same issue. That sounds very plausible. > My guess would be that a worker is trying to dispatch something to the main thread too late in shutdown, so it fails and we leak the runnable. The dispatch in question [is happening here](https://searchfox.org/mozilla-central/rev/684aefab97202faa982dd898f1d99208a46f12b0/dom/workers/remoteworkers/RemoteWorkerChild.cpp#559) in the callback of the `RemoteWorkerChild`'s `WeakWorkerRef`. IIUC the magic of `RemoteWorkerChild::InitializeOnWorker()` we are on the worker thread and - first take a [weak reference of our `RemoteWorkerChild`](https://searchfox.org/mozilla-central/rev/684aefab97202faa982dd898f1d99208a46f12b0/dom/workers/remoteworkers/RemoteWorkerChild.cpp#530) - we then create a `StrongWorkerRef` [that is supposed to keep the worker alive](https://searchfox.org/mozilla-central/rev/684aefab97202faa982dd898f1d99208a46f12b0/dom/workers/remoteworkers/RemoteWorkerChild.cpp#538-544) - we capture that `StrongWorkerRef` in the callback function of a new [`WeakWorkerRef`](https://searchfox.org/mozilla-central/rev/684aefab97202faa982dd898f1d99208a46f12b0/dom/workers/remoteworkers/RemoteWorkerChild.cpp#546-548) to ensure it will live until we receive the callback - once the worker ends, the callback function of the `WeakWorkerRef` will execute the [`NS_ProxyRelease` ](https://searchfox.org/mozilla-central/rev/684aefab97202faa982dd898f1d99208a46f12b0/dom/workers/remoteworkers/RemoteWorkerChild.cpp#559) which allocates the event that will be leaked What is not evident (to me) is: - who actually is the mOwningEventTarget (if it is the main thread as suspected by :mccr8 shouldn't it live longer than the worker?) and which [`Dispatch` function](https://searchfox.org/mozilla-central/search?q=symbol:_ZN14nsIEventTarget8DispatchE16already_AddRefedI11nsIRunnableEj&redirect=false) actually applies ? - what makes the dispatch apparently fail ?
(In reply to Andrew McCreight [:mccr8] from comment #21) > I'm guessing that bug 1717657 is the LeakSanitizer manifestation of the same issue. That sounds very plausible. > My guess would be that a worker is trying to dispatch something to the main thread too late in shutdown, so it fails and we leak the runnable. The dispatch in question [is happening here](https://searchfox.org/mozilla-central/rev/684aefab97202faa982dd898f1d99208a46f12b0/dom/workers/remoteworkers/RemoteWorkerChild.cpp#559) in the callback of the `RemoteWorkerChild`'s `WeakWorkerRef`. IIUC the magic of `RemoteWorkerChild::InitializeOnWorker()` we are on the worker thread and - first take a [weak reference of our `RemoteWorkerChild`](https://searchfox.org/mozilla-central/rev/684aefab97202faa982dd898f1d99208a46f12b0/dom/workers/remoteworkers/RemoteWorkerChild.cpp#530) - we then create a `StrongWorkerRef` [that is supposed to keep the worker alive](https://searchfox.org/mozilla-central/rev/684aefab97202faa982dd898f1d99208a46f12b0/dom/workers/remoteworkers/RemoteWorkerChild.cpp#538-544) - we capture that `StrongWorkerRef` in the callback function of a new [`WeakWorkerRef`](https://searchfox.org/mozilla-central/rev/684aefab97202faa982dd898f1d99208a46f12b0/dom/workers/remoteworkers/RemoteWorkerChild.cpp#546-548) to ensure it will live until we receive the callback - once the worker ends, the callback function of the `WeakWorkerRef` will execute the [`NS_ProxyRelease` ](https://searchfox.org/mozilla-central/rev/684aefab97202faa982dd898f1d99208a46f12b0/dom/workers/remoteworkers/RemoteWorkerChild.cpp#559) which allocates the event that will be leaked What is not evident (to me) is: - who actually is the `mOwningEventTarget` (if it is the main thread as suspected by :mccr8 shouldn't it live longer than the worker?) and which [`Dispatch` function](https://searchfox.org/mozilla-central/search?q=symbol:_ZN14nsIEventTarget8DispatchE16already_AddRefedI11nsIRunnableEj&redirect=false) actually applies ? - what makes the dispatch apparently fail ?