1722991 - Fission crash in [@ nsDocShell::EnsureContentViewer]

Status: RESOLVED FIXED

(Core :: DOM: Navigation, defect, P2)

Description

[Chris Peterson [:cpeterson]]

This is the #2 Fission crash in Beta 91 and Nightly 92.

Over the last six months, 2021 out of 2063 crashes have Fission enabled and 99.8% of the crashes are Windows 10. More than half of the crashes happened during the first minute after launch.

This crash signature is very old, but has increased in Beta and Nightly as we rolled out to more and more Fission users.

Crash report: https://crash-stats.mozilla.org/report/index/f473b2df-7f6a-4982-83e4-6e4f30210729

Reason: EXCEPTION_ACCESS_VIOLATION_READ

Top 10 frames of crashing thread:

0 xul.dll nsDocShell::EnsureContentViewer docshell/base/nsDocShell.cpp:6405
1 xul.dll nsDocShell::CreateContentViewer docshell/base/nsDocShell.cpp:7824
2 xul.dll nsDSURIContentListener::DoContent docshell/base/nsDSURIContentListener.cpp:179
3 xul.dll nsDocumentOpenInfo::TryContentListener uriloader/base/nsURILoader.cpp:596
4 xul.dll nsDocumentOpenInfo::OnStartRequest uriloader/base/nsURILoader.cpp:154
5 xul.dll mozilla::net::HttpChannelChild::DoOnStartRequest netwerk/protocol/http/HttpChannelChild.cpp:564
6 xul.dll std::_Func_impl_no_alloc<`lambda at /builds/worker/checkouts/gecko/netwerk/protocol/http/HttpChannelChild.cpp:352:13', void>::_Do_call 
7 xul.dll mozilla::net::ChannelEventQueue::FlushQueue netwerk/ipc/ChannelEventQueue.cpp:90
8 xul.dll mozilla::net::ChannelEventQueue::ResumeInternal::CompleteResumeRunnable::Run netwerk/ipc/ChannelEventQueue.cpp:148
9 xul.dll mozilla::TaskController::DoExecuteNextTaskOnlyMainThreadInternal xpcom/threads/TaskController.cpp:805

Comment 1

[Chris Peterson [:cpeterson]]

The crash volume is high, but the number of installs is very low:

• Nightly 92: 392 crashes from 9 installs
• Nightly 91: 21 crashes from 8 installs

There are also some EnsureContentViewer crash reports from Fenix Android users.

In bug 523260 comment 22, Olli says one install has dom.cross_origin_iframes_loaded_in_background enabled, which is not support by Fission. Should we remove or rename that pref?

Comment 2

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

(In reply to Chris Peterson [:cpeterson] from comment #1)

In bug 523260 comment 22, Olli says one install has dom.cross_origin_iframes_loaded_in_background enabled, which is not support by Fission. Should we remove or rename that pref?

We should perhaps either remove it or disable it when Fission is enabled, yeah. I don't think we'd want to remove it entirely, but disabling with fission it will work well enough.

There are also some EnsureContentViewer crash reports from Fenix Android users.

I think that's a separate issue, the stacks don't look the same.

Comment 3

[Chris Peterson [:cpeterson]]

Assigning to Olli to disable dom.cross_origin_iframes_loaded_in_background for Fission.

We'll need some perf measurements of dom.cross_origin_iframes_loaded_in_background before we decide whether making the feature Fission-compatible (in a different bug) is worthwhile.

Upgrading from soft to hard blocker since this is a reproducible crash and has an easy fix.

Comment 4

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

Attachment: Bug 1722991, don't try to load iframes in the background when Fission is enabled r=sefeng

The feature isn't Fission compatible at the moment and it is disabled by default any how, so
better to not try to use it with Fission so that some crashes can be avoided.

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/a64809081791
don't try to load iframes in the background when Fission is enabled r=sefeng

Comment 6

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/a64809081791