Closed Bug 1588984 Opened 3 years ago Closed 2 years ago

Crash in [@ mozilla::MozPromise<T>::ThenValueBase::AssertIsDead] from ServiceWorker


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

Windows 10



Tracking Status
firefox71 --- disabled


(Reporter: jesup, Unassigned)



(Keywords: crash)

Crash Data

This bug is for crash report bp-c58dff5f-ec21-4e25-a1df-9c6df0191016.

Note: I hit this updating Nightly with Firefox Private Network turned on but failing to connect to the server, which may or may not matter.

Top 10 frames of crashing thread:

0 xul.dll void mozilla::MozPromise<DiskInfo, nsresult, 0>::ThenValueBase::AssertIsDead xpcom/threads/MozPromise.h:439
1 xul.dll void mozilla::MozPromise<bool, nsTString<char>, 0>::AssertIsDead xpcom/threads/MozPromise.h:976
2 xul.dll void mozilla::MozPromise<bool, nsTString<char>, 0>::AssertIsDead xpcom/threads/MozPromise.h:979
3 xul.dll void mozilla::MozPromise<mozilla::dom::ServiceWorkerRegistrationDescriptor, mozilla::CopyableErrorResult, 0>::~MozPromise xpcom/threads/MozPromise.h:1017
4 xul.dll void mozilla::MozPromise<mozilla::dom::ServiceWorkerRegistrationDescriptor, mozilla::CopyableErrorResult, 0>::Private::~Private xpcom/threads/MozPromise.h:250
5 xul.dll unsigned long mozilla::dom::ServiceWorkerResolveWindowPromiseOnRegisterCallback::Release dom/serviceworkers/ServiceWorkerManager.cpp:567
6 xul.dll void nsTArray_Impl<RefPtr<ID3D11RenderTargetView>, nsTArrayInfallibleAllocator>::~nsTArray_Impl xpcom/ds/nsTArray.h:914
7 xul.dll mozilla::dom::ServiceWorkerJob::~ServiceWorkerJob dom/serviceworkers/ServiceWorkerJob.cpp:119
8 xul.dll void mozilla::dom::ServiceWorkerRegisterJob::~ServiceWorkerRegisterJob dom/serviceworkers/ServiceWorkerRegisterJob.cpp:56
9 xul.dll void nsTArray_Impl<RefPtr<mozilla::dom::ServiceWorkerJob>, nsTArrayInfallibleAllocator>::RemoveElementsAtUnsafe xpcom/ds/nsTArray.h:2309

37 of the 38 crashes in the last week have ServiceWorker in the proto signature

Priority: -- → P2

I also ran into this just now. My report is bp-0318ea71-1560-44a8-872d-a3f270191101

AFAICT this is nightly only?

AFAICT this is nightly only?

The crash signature is a diagnostic, nightly-only assert, so that makes sense.

In Frame 5 I see:
unsigned long mozilla::dom::ServiceWorkerResolveWindowPromiseOnRegisterCallback::Release()

which causes a delete (this) of ServiceWorkerResolveWindowPromiseOnRegisterCallback (see NS_INLINE_DECL_REFCOUNTING_WITH_DESTROY(_class, delete (this), __VA_ARGS__)).

ServiceWorkerResolveWindowPromiseOnRegisterCallback contains a RefPtr<ServiceWorkerRegistrationPromise::Private> mPromise;, which seems to be the last counted reference to this instance. During destruction, thus also the ServiceWorkerRegistrationPromise::Private gets destroyed in a moment it did not expect to be destroyed, it seems. As in this case probably no one expects this promise to be resolved any more, we might want to handle this edge case and do something in ~ServiceWorkerResolveWindowPromiseOnRegisterCallback() if we are owning the last reference to the promise, at least as a fallback. We still might want to understand, if there is an order problem during shutdown, though.

Side note on Frame 6:
void nsTArray_Impl<RefPtr<ID3D11RenderTargetView>, nsTArrayInfallibleAllocator>::~nsTArray_Impl()

Where does ID3D11RenderTargetView (MS Direct3D class) come from? The array that most probably has been destroyed in frame 7 should be nsTArray<RefPtr<Callback>> mResultCallbackList; in ServiceWorkerJob which would match perfectly the ServiceWorkerResolveWindowPromiseOnRegisterCallback::Release() call of frame 5.

Closed: 2 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1606157
You need to log in before you can comment on or make changes to this bug.