Crash in [@ mozilla::dom::BrowsingContext::RestoreChildren]
Categories
(Core :: DOM: Core & HTML, defect, P1)
Tracking
()
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
Comment 2•5 years ago
|
||
STR from dupe bug #1547904
(Mark wrote in bug #1547904 comment #0)
- Browse to https://imgur.com/
- Click on an image (just about any image, apparently, same results with a static image and videos)
- Click on the BACK button
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Comment 3•5 years ago
|
||
I had some issues getting it to reproduce with imgur, but was more lucky with hn.
Updated•5 years ago
|
Assignee | ||
Comment 4•5 years ago
|
||
Also, make sure to evict the right browsing contexts from the cache.
Updated•5 years ago
|
Pushed by afarre@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/11b4d70a2b5d Only restore non-empty browsing context children. r=peterv
Comment 6•5 years ago
|
||
bugherder |
Updated•5 years ago
|
Reporter | ||
Comment 7•5 years ago
|
||
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()).
Comment 8•5 years ago
|
||
This patch did not fix the crashes...
https://crash-stats.mozilla.org/report/index/4dab5951-1287-43cd-ae4f-516890190501
Reporter | ||
Updated•5 years ago
|
Assignee | ||
Comment 9•5 years ago
|
||
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.
Comment 11•5 years ago
|
||
crash numbers are down but still significant for nightly...
Assignee | ||
Comment 12•5 years ago
|
||
Depends on D29669
Assignee | ||
Comment 13•5 years ago
|
||
Unfortunately this patch doesn't take us all the way. Try says:
Assignee | ||
Comment 14•5 years ago
|
||
Unfortunately this patch doesn't take us all the way. Try says:
Updated•5 years ago
|
Comment 15•5 years ago
|
||
The crash is still reproducible for me - https://crash-stats.mozilla.org/report/index/64e3732b-2ca3-4e66-b081-8db9b0190503
Comment 16•5 years ago
|
||
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.
Assignee | ||
Comment 17•5 years ago
|
||
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.
Assignee | ||
Comment 18•5 years ago
|
||
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.
Comment 19•5 years ago
|
||
This is still crashing a lot in the nightlies of 20190502 (2 May), with around 1500 crashes reported.
Updated•5 years ago
|
Assignee | ||
Comment 20•5 years ago
|
||
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+.
Updated•5 years ago
|
Comment 21•5 years ago
|
||
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
Comment 22•5 years ago
|
||
bugherder |
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Comment 23•5 years ago
|
||
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/
Updated•2 years ago
|
Description
•