1474296 - Crash in nsPipe::AdvanceWriteCursor

Status: RESOLVED FIXED

(WebExtensions :: Request Handling, defect, P1)

Description

[Marcia Knous [:marcia]]

This bug was filed from the Socorro interface and is
report bp-0faee110-5c94-433d-bb88-0e90a0180708.
=============================================================

Seen while doing nightly crash triage - 3 unique Mac users hit this on nightly: https://bit.ly/2m7mqRf. All have MOZ_RELEASE_ASSERT(newWriteCursor <= mWriteLimit). The URLS appear to be GMail.

Crashes started using the 20180701220749 build. Possible regression range based on that build ID: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=19766d4c54e3c0ef09caf3c9a7fd3f162e4d5ac6&tochange=3cfc350101967376909ad3c729f9779ae0ab7a94

Top 10 frames of crashing thread:

0 XUL nsPipe::AdvanceWriteCursor xpcom/io/nsPipe3.cpp:927
1 XUL nsPipeOutputStream::WriteSegments xpcom/io/nsPipe3.cpp:1854
2 XUL NS_CopySegmentToStream xpcom/io/nsStreamUtils.cpp:812
3 XUL nsStringInputStream::ReadSegments xpcom/io/nsStringStream.cpp:270
4 XUL mozilla::dom::FetchDriver::OnDataAvailable dom/fetch/FetchDriver.cpp
5 XUL mozilla::net::nsHTTPCompressConv::do_OnDataAvailable netwerk/streamconv/converters/nsHTTPCompressConv.cpp:528
6 XUL mozilla::net::nsHTTPCompressConv::OnDataAvailable netwerk/streamconv/converters/nsHTTPCompressConv.cpp:443
7 XUL mozilla::net::HttpChannelChild::OnTransportAndData netwerk/protocol/http/HttpChannelChild.cpp:995
8 XUL mozilla::net::ChannelEventQueue::FlushQueue netwerk/ipc/ChannelEventQueue.cpp:93
9 XUL mozilla::net::ChannelEventQueue::ResumeInternal netwerk/ipc/ChannelEventQueue.h:329

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

Comment 1

[Eric Rahm [:erahm]]

This looks like a fetch issue. The main thing that jumps out at me is FetchDriver::OnDataAvailable notes that it can be accessed by any thread, but claims it's not an issue [1]. If you expand the crash report you can see threads 32 and 33 and hitting the same code path, I'm inclined to believe that's the underlying issue.

[1] https://searchfox.org/mozilla-central/rev/28daa2806c89684b3dfa4f0b551db1d099dda7c2/dom/fetch/FetchDriver.cpp#1103-1105

Comment 2

[Eric Rahm [:erahm]]

Kris noted this might be WebExtensions breaking some assumptions.

Comment 3

[Kris Maglione [:kmag]]

Yeah, it looks like this happens when we're disconnecting a StreamFilter from a channel. The OnDataAvailable calls being flushed from our queue wind up racing with the ones coming directly from the channel while we disconnect.

This will require some thought.

Comment 4

[Kris Maglione [:kmag]]

Attachment: Bug 1474296: Don't disconnect disconnected channels on IPC error.

This is mostly a guess at the cause of the problem, but I can't see any other
way for us to multiply call OnDataAvailable in parallel during normal
disconnection.

Review commit: https://reviewboard.mozilla.org/r/259440/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/259440/

Comment 5

[Shane Caraveo (:mixedpuppy)]

Comment on attachment 8994943 [details]
Bug 1474296: Don't disconnect disconnected channels on IPC error.

https://reviewboard.mozilla.org/r/259440/#review266482

After retracing all the state stuff, I think this is fine to do.

Comment 6

[Kris Maglione [:kmag]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/4bf70a81f42f205bd2b0c91da3f511ca39c2f118
Bug 1474296: Don't disconnect disconnected channels on IPC error. r=mixedpuppy

Comment 7

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/4bf70a81f42f

Comment 8

[Shane Caraveo (:mixedpuppy)]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=0004c22fa4d2b336ffd30a7d1e88672b90e7fc85

Comment 9

[CosminB]

Is manual testing required on this bug? If yes, please provide some STR and the proper extension(if required) or set the “qe-verify -“ flag.

Thanks!