Closed
Bug 1448928
Opened 7 years ago
Closed 7 years ago
Crash in RtlEnterCriticalSection | mozilla::dom::WorkerPrivate::DispatchPrivate
Categories
(Core :: DOM: Service Workers, defect, P2)
Tracking
()
RESOLVED
DUPLICATE
of bug 1449138
Tracking | Status | |
---|---|---|
firefox61 | --- | fixed |
People
(Reporter: marcia, Assigned: asuth)
References
Details
(Keywords: crash, regression)
Crash Data
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•7 years ago
|
||
22 crashes on windows 10, :asuth can you take a look?
Flags: needinfo?(bugmail)
Updated•7 years ago
|
Priority: -- → P2
Assignee | ||
Comment 2•7 years ago
|
||
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.
Depends on: 1445587
Updated•7 years ago
|
Blocks: ServiceWorkers-stability
Updated•7 years ago
|
Assignee: nobody → bugmail
Assignee | ||
Comment 3•7 years ago
|
||
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.)
Status: NEW → RESOLVED
Closed: 7 years ago
Flags: needinfo?(bugmail)
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•