Closed Bug 1696266 Opened 4 months ago Closed 3 months ago

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

Categories

(Core :: DOM: Navigation, defect)

x86
Windows 10
defect

Tracking

()

VERIFIED FIXED
88 Branch
Fission Milestone M7a
Tracking Status
firefox-esr78 --- unaffected
firefox86 --- unaffected
firefox87 --- unaffected
firefox88 --- fixed
firefox89 --- verified

People

(Reporter: cpeterson, Assigned: smaug)

References

(Blocks 1 open bug, Regression)

Details

(Keywords: crash, regression)

Crash Data

Attachments

(2 files)

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
Fission Milestone: ? → M7a
Assignee: nobody → bugs

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

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.

Pushed by opettay@mozilla.com:
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
Status: NEW → RESOLVED
Closed: 3 months ago
Resolution: --- → FIXED
Target Milestone: --- → 88 Branch
Flags: qe-verify+

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).

Status: RESOLVED → VERIFIED
Flags: qe-verify+
Regressions: 1713365
You need to log in before you can comment on or make changes to this bug.