1713365 - Crash in [@ nsFrameLoaderOwner::ChangeRemotenessCommon]

Status: RESOLVED FIXED

(Core :: DOM: Navigation, defect)

Description

[u608768]

Crash report: https://crash-stats.mozilla.org/report/index/54508e59-ac4d-497e-b95f-8622d0210528

MOZ_CRASH Reason: MOZ_DIAGNOSTIC_ASSERT(false) (The current session history entry has already an nsFrameLoader!)

Top 10 frames of crashing thread:

0 xul.dll nsFrameLoaderOwner::ChangeRemotenessCommon dom/base/nsFrameLoaderOwner.cpp:150
1 xul.dll nsFrameLoaderOwner::ChangeRemotenessToProcess dom/base/nsFrameLoaderOwner.cpp:293
2 xul.dll mozilla::dom::CanonicalBrowsingContext::PendingRemotenessChange::FinishTopContent docshell/base/CanonicalBrowsingContext.cpp:1329
3 xul.dll mozilla::dom::CanonicalBrowsingContext::PendingRemotenessChange::Finish docshell/base/CanonicalBrowsingContext.cpp:1275
4 xul.dll mozilla::MozPromise<bool, nsresult, 1>::ThenValue<`lambda at /builds/worker/checkouts/gecko/docshell/base/CanonicalBrowsingContext.cpp:1260:9', `lambda at /builds/worker/checkouts/gecko/docshell/base/CanonicalBrowsingContext.cpp:1261:9'>::DoResolveOrRejectInternal xpcom/threads/MozPromise.h:846
5 xul.dll mozilla::MozPromise<bool, mozilla::ipc::ResponseRejectReason, 1>::ThenValueBase::ResolveOrRejectRunnable::Run xpcom/threads/MozPromise.h:487
6 xul.dll mozilla::TaskController::DoExecuteNextTaskOnlyMainThreadInternal xpcom/threads/TaskController.cpp:766
7 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1159
8 xul.dll mozilla::ipc::MessagePump::Run ipc/glue/MessagePump.cpp:85
9 xul.dll MessageLoop::RunHandler ipc/chromium/src/base/message_loop.cc:328

All crashes have Fission enabled.

Assertion was added in bug 1696266, but first build with this crash reason appears to be 20210503214210: https://crash-stats.mozilla.org/report/index/414ab4ef-c8d2-47bf-a55a-5f99e0210504.

Comment 1

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

This is the bug I'm looking at.

Comment 2

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

Attachment: Bug 1713365, don't try to bfcache if the session history entry already has a frameloader, r=peterv

The crash happens currently when there are more than one loading session history entries at the same time and when
the latter load then accesses current active entry, it has already the bfcached frameloader.

I have tried and failed to write a testcase for this. The Pernosco record is from running
https://searchfox.org/mozilla-central/source/devtools/client/webconsole/test/browser/browser_webconsole_message_categories.js
and the crash has happened when there is a race condition between a load initiated in the parent process and another load initiated in a child
process.

The patch tries to make the setup rather safe. If active entry has changed or it has gotten frameloader, don't try to bfcache.

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/bb05fe8fa742
don't try to bfcache if the session history entry already has a frameloader, r=peterv

Comment 4

[Atila Butkovits]

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

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

The patch landed in nightly and beta is affected.
:smaug, is this bug important enough to require an uplift?
If not please set status_beta to wontfix.

For more information, please visit auto_nag documentation.

Comment 6

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

This is for bfcache-in-parent which isn't enabled by default