Closed Bug 1547911 Opened 5 years ago Closed 5 years ago

Crash in [@ mozilla::dom::BrowsingContext::RestoreChildren]

Categories

(Core :: DOM: Core & HTML, defect, P1)

68 Branch
Unspecified
All
defect

Tracking

()

VERIFIED FIXED
mozilla68
Fission Milestone M2
Tracking Status
firefox-esr60 --- unaffected
firefox66 --- unaffected
firefox67 --- unaffected
firefox68 + verified

People

(Reporter: calixte, Assigned: farre)

References

(Depends on 1 open bug, Blocks 1 open bug, Regression)

Details

(Keywords: crash, regression, topcrash)

Crash Data

Attachments

(2 files, 1 obsolete file)

This bug is for crash report bp-6f846a2d-8088-4ccb-aa7b-7b51c0190430.

Top 10 frames of crashing thread:

0 xul.dll mozilla::dom::BrowsingContext::RestoreChildren docshell/base/BrowsingContext.cpp:342
1 xul.dll nsresult nsDocShell::RestoreFromHistory docshell/base/nsDocShell.cpp:7871
2 xul.dll nsresult nsDocShell::RestorePresentationEvent::Run docshell/base/nsDocShell.cpp:7310
3 xul.dll nsresult mozilla::SchedulerGroup::Runnable::Run xpcom/threads/SchedulerGroup.cpp:295
4 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1180
5 xul.dll NS_ProcessNextEvent xpcom/threads/nsThreadUtils.cpp:486
6 xul.dll void mozilla::ipc::MessagePump::Run ipc/glue/MessagePump.cpp:88
7 xul.dll MessageLoop::RunHandler ipc/chromium/src/base/message_loop.cc:308
8 xul.dll MessageLoop::Run ipc/chromium/src/base/message_loop.cc:290
9 xul.dll nsBaseAppShell::Run widget/nsBaseAppShell.cpp:137

There are 229 crashes (from 124 installations) in nightly 68 with buildid 20190429215338. In analyzing the backtrace, the regression may have been introduced by patch [1] to fix bug 1471869.

[1] https://hg.mozilla.org/mozilla-central/rev?node=b98bad3d505e

Flags: needinfo?(afarre)

STR from dupe bug #1547904

(Mark wrote in bug #1547904 comment #0)

  1. Browse to https://imgur.com/
  2. Click on an image (just about any image, apparently, same results with a static image and videos)
  3. Click on the BACK button
Assignee: nobody → afarre
Status: NEW → ASSIGNED
Flags: needinfo?(afarre)

I had some issues getting it to reproduce with imgur, but was more lucky with hn.

Priority: -- → P2

Also, make sure to evict the right browsing contexts from the cache.

Priority: P2 → P1
Pushed by afarre@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/11b4d70a2b5d
Only restore non-empty browsing context children. r=peterv
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla68
OS: Windows 7 → All

There still are some crashes after the patch landed (203 crashes in 68 with buildid 20190430215337).
The moz_crash_reason is always: MOZ_RELEASE_ASSERT(mChildren.IsEmpty()).

Status: RESOLVED → REOPENED
Resolution: FIXED → ---

The assert is a MOZ_DIAGNOSTIC_ASSERT, so the "crash" will only affect nightly. I'll continue working on this tomorrow when I'm back from PTO.

crash numbers are down but still significant for nightly...

Depends on D29669

Unfortunately this patch doesn't take us all the way. Try says:

Fission Milestone: --- → M3

Hello Andreas - there are quite a few crashes building up (over 8K), and many mobile users are crashing every time they press the back button on their device. Can we consider backing out the regressing bug until we can find a proper fix? Thanks.

Flags: needinfo?(afarre)
Keywords: topcrash

This is essentially equal to restoring cached children and removing
current children from a BrowsingContext, which is the correct
behaviour. It would've been better if the current children were
removed in a more transparent manner, but it is more important to
remove an assert that too eagerly triggers.

I've convinced myself that it would be OK to just remove the assert, as in comment 17. I can't currently push to try due to bug 1548973, so unfortunately we can't check that out. I think that that would be easier than backing out.

Flags: needinfo?(afarre)

This is still crashing a lot in the nightlies of 20190502 (2 May), with around 1500 crashes reported.

Attachment #9062709 - Attachment description: Bug 1547911 - Don't assert that there are no children when restoring BC. r=nika → Bug 1547911 - Don't assert that there are no children when restoring BC. r=peterv

Try is looking promising : https://treeherder.mozilla.org/#/jobs?repo=try&revision=6d48429983139810958f62e995e1eaaf4ef2f369&group_state=expanded

I'll land this as early I can after getting that r+.

Attachment #9062709 - Attachment description: Bug 1547911 - Don't assert that there are no children when restoring BC. r=peterv → Bug 1547911 - Don't assert that there are no children when restoring BC. r=nika
Pushed by afarre@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/f59b3336d254
Don't assert that there are no children when restoring BC. r=nika
Status: REOPENED → RESOLVED
Closed: 5 years ago5 years ago
Resolution: --- → FIXED
Attachment #9062481 - Attachment is obsolete: true
Fission Milestone: M3 → M2

I'm confirming that bug is fixed, no more crashes in Mozilla Firefox Nightly 68.0a1 (2019-05-06) looking at Reports, so I'm marking this bug as VERIFIED.
Thank you very much! \o/

Status: RESOLVED → VERIFIED
Version: Trunk → 68 Branch
Has Regression Range: --- → yes
You need to log in before you can comment on or make changes to this bug.