1547076 - Crash in [@ mozilla::net::HttpChannelChild::RecvOnStartRequest]

Status: RESOLVED DUPLICATE of bug 1572032

(Core :: Networking: HTTP, defect, P1)

Description

[Marcia Knous [:marcia]]

This bug is for crash report bp-92332478-9cb8-4cf9-8eb7-b3c930190425.

Seen while looking at nightly crash stats - several Mac and Linux crashes in recent nightlies, starting with 20190420095532: https://bit.ly/2PrO35s

All have Moz Crash reason MOZ_RELEASE_ASSERT(!mDivertingToParent) (mDivertingToParent should be unset before OnStartRequest!)

There also appears to be a several Win crashes in 66.0.3 with the same signature. Not sure if is the same issue.

Top 10 frames of crashing thread:

0 XUL mozilla::net::HttpChannelChild::RecvOnStartRequest netwerk/protocol/http/HttpChannelChild.cpp:490
1 XUL mozilla::net::PHttpChannelChild::OnMessageReceived ipc/ipdl/PHttpChannelChild.cpp:786
2 XUL mozilla::ipc::MessageChannel::DispatchMessage ipc/glue/MessageChannel.cpp:2151
3 XUL mozilla::ipc::MessageChannel::MessageTask::Run ipc/glue/MessageChannel.cpp:1968
4 XUL mozilla::SchedulerGroup::Runnable::Run xpcom/threads/SchedulerGroup.cpp:295
5 XUL nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1180
6 XUL NS_ProcessNextEvent xpcom/threads/nsThreadUtils.cpp:486
7 XUL mozilla::ipc::MessagePump::Run ipc/glue/MessagePump.cpp:110
8 XUL nsBaseAppShell::Run widget/nsBaseAppShell.cpp:137
9 XUL nsAppShell::Run widget/cocoa/nsAppShell.mm:705

Comment 1

[Honza Bambas (:mayhemer)]

Looks like an old crash with low rate, P2.

Comment 2

[Robin Whittleton]

I’m reliably hitting this on https://standardebooks.org/vocab/1.0 .

Comment 3

[Andrew McCreight [:mccr8]]

#3 Windows top crash on the August 7th Nightlies.

Comment 4

[Marcia Knous [:marcia]]

I tried reproducing this on Mac 70 nightly with the site in Comment 1. On Mac I get a dialog that says "Alert - There is not sufficient memory to complete the action you requested. And then when I close it I get the tab crash - https://crash-stats.mozilla.org/report/index/5ba695ce-8d26-4cb8-a50f-dcec50190813.

This is the #6 top crash on 70 nightly currently.

Comment 5

[Kershaw Chang [:kershaw]]

I got this assertion from my local build firefox with the URL https://standardebooks.org/vocab/1.0.

Assertion failure: !mStartSent, at /Users/changkershaw/work/gecko/netwerk/protocol/http/HttpBackgroundChannelChild.cpp:116
#01: mozilla::net::PHttpBackgroundChannelChild::OnMessageReceived(IPC::Message const&)[/Users/changkershaw/work/gecko/obj-x86_64-apple-darwin18.6.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0xa607d6]
#02: mozilla::ipc::PBackgroundChild::OnMessageReceived(IPC::Message const&)[/Users/changkershaw/work/gecko/obj-x86_64-apple-darwin18.6.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0xace309]
#03: mozilla::ipc::MessageChannel::DispatchAsyncMessage(mozilla::ipc::ActorLifecycleProxy*, IPC::Message const&)[/Users/changkershaw/work/gecko/obj-x86_64-apple-darwin18.6.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0x896a30]

It shows that we send two OnStartRequest to child process.
The second OnStartRequest is called from:

    frame #0: 0x000000011066f207 XUL`mozilla::net::HttpChannelParent::OnStartRequest(this=<unavailable>, aRequest=<unavailable>) at HttpChannelParent.cpp:1354:3 [opt]
    frame #1: 0x000000011050c5bb XUL`nsUnknownDecoder::FireListenerNotifications(this=0x00000001b1a98300, request=0x00000001b19b0000, aCtxt=0x0000000000000000) at nsUnknownDecoder.cpp:722:18 [opt]
    frame #2: 0x000000011050d34b XUL`nsUnknownDecoder::OnStopRequest(this=0x00000001b1a98300, request=0x00000001b19b0000, aStatus=NS_OK) at nsUnknownDecoder.cpp:295:10 [opt]
    frame #3: 0x00000001106e85cd XUL`mozilla::net::nsHttpChannel::ContinueOnStopRequest(this=0x00000001b19b0000, aStatus=NS_OK, aIsFromNet=<unavailable>, aContentComplete=<unavailable>) at nsHttpChannel.cpp:8264:16 [opt]
    frame #4: 0x00000001106e6603 XUL`mozilla::net::nsHttpChannel::OnStopRequest(this=0x00000001b19b0000, request=0x00000001311a0400, status=NS_OK) at nsHttpChannel.cpp:8030:10 [opt]
    frame #5: 0x000000011028f09d XUL`nsInputStreamPump::OnStateStop(this=0x00000001311a0400) at nsInputStreamPump.cpp:655:16 [opt]
    frame #6: 0x000000011028e4b1 XUL`nsInputStreamPump::OnInputStreamReady(this=0x00000001311a0400, stream=<unavailable>) at nsInputStreamPump.cpp:403:21 [opt]
    frame #7: 0x000000011028f3fd XUL`non-virtual thunk to nsInputStreamPump::OnInputStreamReady(this=<unavailable>, stream=<unavailable>) at nsInputStreamPump.cpp:0 [opt]

Comment 6

[Kershaw Chang [:kershaw]]

I think this bug is regressed by https://hg.mozilla.org/mozilla-central/rev/0aa6dca8717afcf336ed340caa233841104701c5.
Since the response header from https://standardebooks.org/vocab/1.0 contains "x-content-type-options: nosniff", nsUnknownDecoder::mContentType is always empty. Thus, OnStartRequest is called twice at [1] and [2].

Sebastian, could you take a look?

[1] https://searchfox.org/mozilla-central/rev/c7e8bc4996f979e5876b33afae3de3b1ab4f3ae1/netwerk/streamconv/converters/nsUnknownDecoder.cpp#199
[2] https://searchfox.org/mozilla-central/rev/c7e8bc4996f979e5876b33afae3de3b1ab4f3ae1/netwerk/streamconv/converters/nsUnknownDecoder.cpp#295

Comment 7

[Sebastian Streich [:sstreich]]

Hey, can confirm that is the case. I'll have a patch ready soon.
@kershaw thank you very much for the input here to pin the error down!

Btw we might want to reach out to https://standardebooks.org/ - They're sending Nosniff but no Content-Type.
So even with the patch the page will be broken on ff 70+

Comment 8

[Robin Whittleton]

I can get that page on standardebooks fixed.

Comment 9

[Christoph Kerschbaumer [:ckerschb]]

Basti provided a patch over in Bug 1572032.

Comment 10

[Robin Whittleton]

(For future reference, the SE bug was fixed in https://github.com/standardebooks/web/issues/38 )