1448928 - Crash in RtlEnterCriticalSection | mozilla::dom::WorkerPrivate::DispatchPrivate

Status: RESOLVED DUPLICATE of bug 1449138

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

Description

[Marcia Knous [:marcia]]

This bug was filed from the Socorro interface and is
report bp-2bf9f8e6-beb5-4bf9-ae23-a2d0e0180319.
=============================================================

Seen while looking at crash stats - crashes started using 20180317220121: https://bit.ly/2DWyewg

Possible regression range based on build ID: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=9cd8e03d9e472f07041be3cd80cc95a8194f91a5&tochange=3cec10b16594fb2206fe90337077103906720506

Top 10 frames of crashing thread:

0 ntdll.dll RtlEnterCriticalSection 
1 xul.dll mozilla::dom::WorkerPrivate::DispatchPrivate dom/workers/WorkerPrivate.cpp:1523
2 xul.dll mozilla::dom::WorkerRunnable::DispatchInternal dom/workers/WorkerRunnable.cpp:112
3 xul.dll mozilla::dom::WorkerRunnable::Dispatch dom/workers/WorkerRunnable.cpp:96
4 xul.dll static nsresult mozilla::dom::`anonymous namespace'::ConsumeBodyDoneObserver<mozilla::dom::Response>::OnStreamComplete dom/fetch/FetchConsumer.cpp:256
5 xul.dll mozilla::net::nsStreamLoader::OnStopRequest netwerk/base/nsStreamLoader.cpp:108
6 xul.dll nsInputStreamPump::OnStateStop netwerk/base/nsInputStreamPump.cpp:708
7 xul.dll nsInputStreamPump::OnInputStreamReady netwerk/base/nsInputStreamPump.cpp:436
8 xul.dll nsInputStreamReadyEvent::Run xpcom/io/nsStreamUtils.cpp:102
9 xul.dll mozilla::ThrottledEventQueue::Inner::ExecuteRunnable xpcom/threads/ThrottledEventQueue.cpp:193

=============================================================

Comment 1

[Marion Daly [:mdaly]]

22 crashes on windows 10, :asuth can you take a look?

Comment 2

[Andrew Sutherland [:asuth] (he/him)]

Based on regression range and crash area, this is likely fallout from bug 1445587.  Going to briefly investigate ownership coverage now, will clear NI on completion.

Comment 3

[Andrew Sutherland [:asuth] (he/him)]

The ownership coverage looked fine[1], but it looks like bug 1449138 wherein the StrongWorkerRef wouldn't actually keep the WorkerPrivate alive is the problem, which led to the null deref as SharedMutex's RefPtr mMutex became null, which is what the 0x8 deref crash looks like.

1: Unless the nsInputStreamReadyEvent::Cancel() was invoked, which together with NullifyConsumeBodyPump() would have potentially resulted in the the strong refs for the pump going to zero and thereby for ConsumeBodyDoneObserver as well.  But by invariant and code, Cancel won't happen if Run is happening, so that's just an interesting risk.  (Cancel is used primarily in the case of Workers where Runnables are doomed to never run because the worker shutdown.  It's also used in a few places where the runnable is minted for Dispatch() at a later date after some other event happens; in those cases, the owner calls Cancel() if it decides it won't Dispatch() them.  That idiom is being superseded by the use of MozPromise.)