1722378 - MOZ_CRASH(Content child abort due to IPC error) crash in [@ IPCError-content | RecvConstructBrowser Null or discarded initial BrowsingContext]

Status: RESOLVED FIXED

(Core :: DOM: Content Processes, defect, P2)

Description

[Chris Peterson [:cpeterson]]

This is the top crash among Fission Beta users.

Looks like this crash started spiking in Nightly 91 around June 11 in buildid 20210611213935.

Crash report: https://crash-stats.mozilla.org/report/index/dbdf9990-e8e4-4373-af00-1f7250210726

MOZ_CRASH Reason: MOZ_CRASH(Content child abort due to IPC error)

Top 10 frames of crashing thread:

0 xul.dll mozilla::dom::ContentChild::ProcessingError dom/ipc/ContentChild.cpp:2227
1 xul.dll static mozilla::ipc::IPCResult::Fail ipc/glue/ProtocolUtils.cpp:63
2 xul.dll mozilla::dom::ContentChild::RecvConstructBrowser dom/ipc/ContentChild.cpp:1740
3 xul.dll mozilla::dom::PContentChild::OnMessageReceived ipc/ipdl/PContentChild.cpp:8449
4 xul.dll mozilla::ipc::MessageChannel::DispatchMessage ipc/glue/MessageChannel.cpp:2011
5 xul.dll mozilla::TaskController::DoExecuteNextTaskOnlyMainThreadInternal xpcom/threads/TaskController.cpp:805
6 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1148
7 xul.dll mozilla::ipc::MessagePump::Run ipc/glue/MessagePump.cpp:85
8 xul.dll MessageLoop::RunHandler ipc/chromium/src/base/message_loop.cc:324
9 xul.dll MessageLoop::Run ipc/chromium/src/base/message_loop.cc:306

Comment 1

[Chris Peterson [:cpeterson]]

Here is the pushlog for buildid 20210611213935:

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=47cad7171df3d3c42ee430049c76da2272ae372a&tochange=828dd9f79646057b0f4beda272f2e48ad570a9ba

And the pushlog for the build before it:

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=8508c35e49793fbe402ad2a706a57fabd1c2b0c4&tochange=47cad7171df3d3c42ee430049c76da2272ae372a

Some changesets that might be interesting:

Gabriele Svelto — Bug 1697895 - Register the WER runtime exception module in child processes r=KrisWright
Olli Pettay — Bug 1715865 - Make BrowsingContext skippable, r=nika,mccr8

Comment 2

[Pascal Chevrel:pascalc]

Tracking this Fission crash for 92.

Comment 3

[Chris Peterson [:cpeterson]]

This bug is a hard blocker for Fission M8.

Comment 4

[Nika Layzell [:nika] (ni? for response)]

Attachment: Bug 1722378 - Part 1: Include more information in crashes due to a BrowsingContext being discarded, r=smaug

This should hopefully make it easier to figure out the cause of future crashes
from this assertion by including slightly more information in the crash
message. This should be helpful if the changes in part 2 don't end up fixing
the underlying issue.

Comment 5

[Nika Layzell [:nika] (ni? for response)]

Attachment: Bug 1722378 - Part 2: Ensure we don't try to initialize a nsFrameLoader multiple times, r=smaug

I'm unsure if this is the cause of our crashes, but there is a chance that we
are somehow attempting to re-initialize a nsFrameLoader after it has been
destroyed, and thus re-connecting to a process which has has an
already-destroyed browser. This adds a flag to prevent initialization from
being attempted multiple times for a nsFrameLoader.

Depends on D121687

Comment 6

[Nika Layzell [:nika] (ni? for response)]

Attachment: Bug 1722378 - Part 3: Use AncestorsAreCurrent in InitWithProcess, r=smaug

This method was added since the original checks were written, and implements
roughly the same behaviour.

Depends on D121688

Comment 7

[Nika Layzell [:nika] (ni? for response)]

Attachment: Bug 1722378 - Part 4: Use mInitialized to determine whether to expose BrowsingContext from nsFrameLoader, r=smaug

Without this change, the initialized changes cause failures around
crashed tabs, as the frameLoader.browsingContext getter returns null
after the tab has crashed due to being unable to start a new remote
browser or docshell using the same browsingContext.

The new behaviour avoids creating duplicate hosts for a given
BrowsingContext by instead returning the existing potentially-discarded
browsingContext in these situations.

Depends on D121689

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/f5c261729985
Part 1: Include more information in crashes due to a BrowsingContext being discarded, r=smaug
https://hg.mozilla.org/integration/autoland/rev/b3e6aa128a1f
Part 2: Ensure we don't try to initialize a nsFrameLoader multiple times, r=smaug
https://hg.mozilla.org/integration/autoland/rev/9f0ffc7bd7b4
Part 3: Use AncestorsAreCurrent in InitWithProcess, r=smaug
https://hg.mozilla.org/integration/autoland/rev/35f7746d068f
Part 4: Use mInitialized to determine whether to expose BrowsingContext from nsFrameLoader, r=smaug

Comment 9

[Iulian Moraru]

https://hg.mozilla.org/mozilla-central/rev/f5c261729985
https://hg.mozilla.org/mozilla-central/rev/b3e6aa128a1f
https://hg.mozilla.org/mozilla-central/rev/9f0ffc7bd7b4
https://hg.mozilla.org/mozilla-central/rev/35f7746d068f

Comment 10

[Chris Peterson [:cpeterson]]

Nika's patches added new crash signatures and reasons

https://hg.mozilla.org/integration/autoland/rev/f5c261729985

• Crashes with reason "Cannot create OOP iframe in the same process as its parent document"

• Crashes with reason "bc cannot have become discarded"

• "missing initial frame BrowsingContext"

• "missing initial top BrowsingContext"

• "discarded initial frame BrowsingContext"

• "discarded initial top BrowsingContext"