Crash in nsPipe::AdvanceWriteCursor

RESOLVED FIXED in Firefox 63


Last year
11 months ago


(Reporter: marcia, Assigned: kmag)


({crash, regression})

Bug Flags:
qe-verify -

Firefox Tracking Flags

(firefox-esr52 unaffected, firefox-esr60 unaffected, firefox61 unaffected, firefox62 unaffected, firefox63 fixed)


(crash signature)


(1 attachment)

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: 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:

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

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.

Component: XPCOM → DOM
Kris noted this might be WebExtensions breaking some assumptions.
Component: DOM → General
Flags: needinfo?(kmaglione+bmo)
Product: Core → WebExtensions
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.
Assignee: nobody → kmaglione+bmo
Component: General → Request Handling
Flags: needinfo?(kmaglione+bmo)
Priority: -- → P1
Comment on attachment 8994943 [details]
Bug 1474296: Don't disconnect disconnected channels on IPC error.

After retracing all the state stuff, I think this is fine to do.
Attachment #8994943 - Flags: review?(mixedpuppy) → review+
Bug 1474296: Don't disconnect disconnected channels on IPC error. r=mixedpuppy
Closed: Last year
Resolution: --- → FIXED
Target Milestone: --- → mozilla63
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.

Flags: needinfo?(mixedpuppy)
Flags: needinfo?(mixedpuppy) → qe-verify-
You need to log in before you can comment on or make changes to this bug.