Bug 1610692 Comment 4 Edit History

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

Interesting. The following is happening all on the same thread 1616 / stack trace:

1. We want to register a new service worker. (ServiceWorkerContainer.cpp:390 — global->GetOrCreateServiceWorkerRegistration(aDesc);)
2. The construction of the RemoteServiceWorkerRegistrationImpl initializes mOuter = nullptr. 
3. We dispatch the state "activated". (ServiceWorker.cpp:156 — DOMEventTargetHelper::DispatchTrustedEvent(NS_LITERAL_STRING("statechange"));)
4. During dispatch, we call the cycle collector (I assume, this can happen randomly on any event dispatching). (nsJSEnvironment.cpp:1535 — nsCycleCollector_collect(aListener);)
5. The cycle collector recognizes the ServiceWorkerRegistration we are coming from as dangling and destroys it (ServiceWorkerRegistration.cpp:57 — ServiceWorkerRegistration::~ServiceWorkerRegistration)
6. The deconstruction of ServiceWorkerRegistration wants to clear a never set inner registration and fails. (RemoteServiceWorkerRegistrationImpl::ClearServiceWorkerRegistration)

I assume, that it is not wanted that ServiceWorkerRegistration is being destroyed by the cycle collector during the ongoing registration process. So probably we want to prevent this.

I am also wondering, if it is in general a good idea to let the cycle collector allow to run during a synchronous event dispatching?
Interesting. The following is happening all on the same thread 1616 / stack trace:

1. We want to register a new service worker. (ServiceWorkerContainer.cpp:390 — global->GetOrCreateServiceWorkerRegistration(aDesc);)
2. The construction of the RemoteServiceWorkerRegistrationImpl initializes mOuter = nullptr. 
3. We dispatch the state "activated". (ServiceWorker.cpp:156 — DOMEventTargetHelper::DispatchTrustedEvent(NS_LITERAL_STRING("statechange"));)
4. During dispatch, we call the cycle collector (I assume, this can happen randomly on any event dispatching). (nsJSEnvironment.cpp:1535 — nsCycleCollector_collect(aListener);)
5. The cycle collector recognizes the ServiceWorkerRegistration we are coming from as dangling and destroys it (ServiceWorkerRegistration.cpp:57 — ServiceWorkerRegistration::~ServiceWorkerRegistration)
6. The deconstruction of ServiceWorkerRegistration wants to clear a never set inner registration and fails. (RemoteServiceWorkerRegistrationImpl::ClearServiceWorkerRegistration)

I assume, that it is not wanted that ServiceWorkerRegistration is being destroyed by the cycle collector during the ongoing registration process. So probably we want to prevent this.

I am also wondering, if it is in general a good idea to let the cycle collector allow to run during a synchronous event dispatching? Or is this part of the fuzzing logic in order to provoke more failures?

Back to Bug 1610692 Comment 4