1696266 - fission.bfcacheInParent? Crash in [@ nsFrameLoader::~nsFrameLoader]

Status: VERIFIED FIXED

(Core :: DOM: Navigation, defect)

Description

[Chris Peterson [:cpeterson]]

I suspect this crash is a regression from bfcacheInParent bug 1689601.

I hit this crash three times today. STR that worked twice:

1. Enable fission.bfcacheInParent pref and restart Nightly.
2. Open a new tab.
3. Entered part of the URL for a page I know is in my history: https://online.officetimeline.com/app/#/file/55b995a1-9166-40f7-bb4e-bfcae230d848 (The site requires an account to login, but I think you can register a free account.)

Result:

The tab shows the page title for officetimeline.com but then keeps reloading the page again and again. Eventually the parent process crashes.

mccr8 says he thinks this assertion means that ~nsFrameLoader was called before nsFrameLoader::Destroy().

Crash report: https://crash-stats.mozilla.org/report/index/9f83cee3-51f6-449c-a305-9a59b0210303

MOZ_CRASH Reason: MOZ_RELEASE_ASSERT(mDestroyCalled)

Top 10 frames of crashing thread:

0 xul.dll nsFrameLoader::~nsFrameLoader dom/base/nsFrameLoader.cpp:207
1 xul.dll nsFrameLoader::cycleCollection::DeleteCycleCollectable dom/base/nsFrameLoader.h:131
2 xul.dll nsPurpleBuffer::VisitEntries<SnowWhiteKiller> xpcom/base/nsCycleCollector.cpp:943
3 xul.dll nsCycleCollector::FreeSnowWhiteWithBudget xpcom/base/nsCycleCollector.cpp:2627
4 xul.dll AsyncFreeSnowWhite::Run js/xpconnect/src/XPCJSRuntime.cpp:154
5 xul.dll IdleRunnableWrapper::Run xpcom/threads/nsThreadUtils.cpp:364
6 xul.dll mozilla::TaskController::DoExecuteNextTaskOnlyMainThreadInternal xpcom/threads/TaskController.cpp:760
7 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1158
8 xul.dll mozilla::ipc::MessagePump::Run ipc/glue/MessagePump.cpp:87
9 xul.dll MessageLoop::RunHandler ipc/chromium/src/base/message_loop.cc:328

Comment 1

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

Set release status flags based on info from the regressing bug 1689601

Comment 2

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

aha, the page is actually doing a reload and such load shouldn't use bfcache.

Comment 3

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

Attachment: Bug 1696266, limit the load types which may cause the page to enter bfcache, r=peterv

The change to dom/base/nsFrameLoaderOwner.cpp is to log about the issues but still ensure we don't crash.

I'd prefer to not put error loads to bfcache.

Comment 4

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

Attachment: Bug 1696266, test reloading a page which might otherwise enter bfcache, r=peterv

Depends on D107300

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/acafbde0a546
limit the load types which may cause the page to enter bfcache, r=peterv
https://hg.mozilla.org/integration/autoland/rev/48d93d434ff1
test reloading a page which might otherwise enter bfcache, r=peterv

Comment 6

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/acafbde0a546
https://hg.mozilla.org/mozilla-central/rev/48d93d434ff1

Comment 7

[Vlad Lucaci, Desktop QA (:vlucaci)]

Hello ,

Reproduced this issue with 88.0a1 (2021-03-03) on Windows10x64.
Confirming this issue as verified fixed using Win10x64, macOS 10.15.7 and Ubuntu 20.04 with Nightly 89.0a1(20210413214314).