1684738 - Crash in [@ mozilla::dom::JSStreamConsumer::~JSStreamConsumer]

Status: RESOLVED WORKSFORME

(Core :: DOM: Networking, defect)

Description

[Gabriele Svelto [:gsvelto]]

Crash report: https://crash-stats.mozilla.org/report/index/29d8ead6-6529-4351-ac76-3e0400201225

MOZ_CRASH Reason: MOZ_DIAGNOSTIC_ASSERT(false) (NS_SUCCEEDED(mOwningEventTarget->Dispatch(destroyer.forget())))

Top 10 frames of crashing thread:

0 libxul.so mozilla::dom::JSStreamConsumer::~JSStreamConsumer dom/fetch/FetchUtil.cpp:346
1 libxul.so mozilla::dom::JSStreamConsumer::Release dom/fetch/FetchUtil.cpp:455
2 libxul.so nsPipeEvents::~nsPipeEvents xpcom/io/nsPipe3.cpp:1133
3 libxul.so nsPipeOutputStream::WriteSegments xpcom/io/nsPipe3.cpp:1704
4 libxul.so NS_CopySegmentToStream xpcom/io/nsStreamUtils.cpp:749
5 libxul.so nsStringInputStream::ReadSegments xpcom/io/nsStringStream.cpp:316
6 libxul.so mozilla::dom::FetchDriver::OnDataAvailable dom/fetch/FetchDriver.cpp:1304
7 libxul.so nsCORSListenerProxy::OnDataAvailable netwerk/protocol/http/nsCORSListenerProxy.cpp:638
8 libxul.so mozilla::net::nsHTTPCompressConv::do_OnDataAvailable netwerk/streamconv/converters/nsHTTPCompressConv.cpp:535
9 libxul.so mozilla::net::nsHTTPCompressConv::BrotliHandler netwerk/streamconv/converters/nsHTTPCompressConv.cpp:241

Note that this crash had fission enabled but most of the crashes under this signature don't.

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

Especially in the workers Dispatch may fail.

Comment 2

[Dragana Damjanovic [:dragana]]

Should we move the bug to workers as you mentioned on the slack that it is workers-related?

Comment 3

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

The bug would appear to be in how JSStreamConsumer handles operating in a worker context (that is, when mWorkerStreamOwner is non-null), not in workers. JSStreamConsumer is a part of the fetch implementation, and so this seems like the right component. That said, this likely wants to be fixed by someone on the workers team (or :smaug! ;) and I am strongly considering that we eliminate the concept of discarding (previously cancellation) of runnables and the corresponding inconsistent refusal to dispatch runnables during worker shutdown. The threads can still go away though, so runnables can't always dispatch. It might make sense to fold dispatch into the worker refs to this end.

Comment 4

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

Re-needinfo-ing myself to look more at this bug and potentially set dependencies on overhauling the worker dispatch / workerref relationship in works in general.

Comment 5

[Valentin Gosu [:valentin] (he/him)]

This assertion seems to have been removed at some point. No crashes since 94.