Bugzilla

I was able to reproduce it on Windows this way, but I am not sure if it really helps me. I probably need to instrument the code a bit to see something.

(In reply to Bugmon [:jkratzer for issues] from comment #10)
> A pernosco session for this bug can be found [here](https://pernos.co/debug/yO36A6rER_WnIzNzWKO4tA/index.html).

In the meantime I also commented the older pernosco session a bit. In the "normal case" a worker global seems to be unlinked by the cycle collector in the [repeatGCCC loop](https://searchfox.org/mozilla-central/rev/7fc94186f1a759790c56e41a90ab350d78dbda30/dom/workers/RuntimeService.cpp#2150,2154-2164) after calling the `UnrootGlobalScopes()`, as expected - see first 5 entries in the notebook.

In the failing case, this does not happen but interestingly during CC shutdown we [move our global ptr to a smart ptr](https://searchfox.org/mozilla-central/rev/7fc94186f1a759790c56e41a90ab350d78dbda30/dom/bindings/BindingUtils.h#2765) during `CycleCollectedJSRuntime::DeferredFinalize` as if we wanted to destroy it later and even destroy that `nsCOMPtr` later, but without our refcount going to 0 but to 1. In other words: CC handling seems to be fine and works as expected, and there is apparently a non-CC managed owning reference somewhere else. Or even worse maybe just a manual `AddRef` without even leaving traces of the pointer in memory, given that I did not find any suspicious by inspecting in gdb. Not sure where to go from here...

I was able to reproduce it on Windows this way, but I am not sure if it really helps me. I probably need to instrument the code a bit to see something.

(In reply to Bugmon [:jkratzer for issues] from comment #10)
> A pernosco session for this bug can be found [here](https://pernos.co/debug/yO36A6rER_WnIzNzWKO4tA/index.html).

In the meantime I also commented the older pernosco session a bit. In the "normal case" a worker global seems to be unlinked by the cycle collector in the [repeatGCCC loop](https://searchfox.org/mozilla-central/rev/7fc94186f1a759790c56e41a90ab350d78dbda30/dom/workers/RuntimeService.cpp#2150,2154-2164) after calling the `UnrootGlobalScopes()`, as expected - see first 5 entries in the notebook.

In the failing case, this does not happen but interestingly during CC shutdown we [move our global ptr to a smart ptr](https://searchfox.org/mozilla-central/rev/7fc94186f1a759790c56e41a90ab350d78dbda30/dom/bindings/BindingUtils.h#2765) during `CycleCollectedJSRuntime::DeferredFinalize` as if we wanted to destroy it later and even destroy that `nsCOMPtr` later, but without our refcount going to 0 but to 1. In other words: CC handling seems to be fine and works as expected, and there is apparently a non-CC managed owning reference somewhere else. Or even worse maybe just a manual `AddRef` without even leaving traces of the pointer in memory, given that I did not find any suspicious by inspecting memory in gdb. Not sure where to go from here...