Fission crash in [@ nsGlobalWindowInner::ThawInternal] | MOZ_DIAGNOSTIC_ASSERT(IsSuspended())
Categories
(Core :: DOM: Core & HTML, defect, P2)
Tracking
()
People
(Reporter: gsvelto, Assigned: smaug)
Details
(Keywords: crash, Whiteboard: qa-not-actionable)
Crash Data
Attachments
(1 file)
|
48 bytes,
text/x-phabricator-request
|
pascalc
:
approval-mozilla-beta+
|
Details | Review |
This bug is for crash report bp-ee165c3b-ece5-43d7-a916-e9f2c0190920.
Top 10 frames of crashing thread:
0 xul.dll void nsGlobalWindowInner::ThawInternal dom/base/nsGlobalWindowInner.cpp:5274
1 xul.dll static nsGlobalWindowInner::CallState nsGlobalWindowInner::CallOnChildren<void dom/base/nsGlobalWindowInner.cpp:5399
2 xul.dll void nsGlobalWindowInner::ThawInternal dom/base/nsGlobalWindowInner.cpp:5276
3 xul.dll nsGlobalWindowInner::Thaw dom/base/nsGlobalWindowInner.cpp:5267
4 xul.dll nsresult nsGlobalWindowOuter::RestoreWindowState dom/base/nsGlobalWindowOuter.cpp:7511
5 xul.dll nsresult nsDocShell::RestoreFromHistory docshell/base/nsDocShell.cpp:7908
6 xul.dll nsresult nsDocShell::RestorePresentationEvent::Run docshell/base/nsDocShell.cpp:7340
7 xul.dll mozilla::SchedulerGroup::Runnable::Run xpcom/threads/SchedulerGroup.cpp:295
8 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1225
9 xul.dll NS_ProcessNextEvent xpcom/threads/nsThreadUtils.cpp:486
Low-volume crash on all platforms, most likely because it's triggered by a diagnostic assertion so it should be happening only on nightly and beta. We're tripping over this assertion:
Updated•6 years ago
|
Updated•4 years ago
|
Comment 1•4 years ago
|
||
When searching through the last four weeks of Fission crash pings, I see 237 Aurora crash pings and 75 Nightly crash pings with crash reason MOZ_DIAGNOSTIC_ASSERT(IsSuspended());. I only see 21 user-submitted crash reports with this crash reason, e.g. bp-564cfc51-a6df-4e07-ad44-fec1b0211010. 100% of these crash pings and reports have Fission enabled.
Comment 2•4 years ago
|
||
We are thawing a GlobalWindow that is not suspended. This is an issue in bfcache, both Fission's new bfcache and the old bfcache implementation.
Assigning to Olli because he knows what's going wrong.
This crash is a MOZ_DIAGNOSTIC_ASSERT, so the crash only affects Nightly and Dev Edition. In Beta and Release, a page will be infinitely frozen because we will underflow the freeze counter.
| Assignee | ||
Updated•4 years ago
|
| Assignee | ||
Comment 3•4 years ago
|
||
Comment 5•4 years ago
|
||
| bugherder | ||
Comment 6•4 years ago
|
||
(In reply to Sebastian Hengst [:aryx] (needinfo on intermittent or backout) from comment #5)
Setting status-firefox95=fixed because the changeset above says milestone 95.0a1.
Updated•4 years ago
|
Comment 7•4 years ago
|
||
Looks like I was wrong about this fix landing in Beta 95. The fix added a new test but don't see it in mozilla-beta: https://hg.mozilla.org/releases/mozilla-beta/file/tip/docshell/test/navigation/test_bug1583110.html
| Assignee | ||
Comment 8•4 years ago
•
|
||
Comment on attachment 9248070 [details]
Bug 1583110, freeze/thaw in a separate step, r=peterv
Beta/Release Uplift Approval Request
- User impact if declined: When a page comes out for bfcache and adds an iframe during pageshow event listener, the iframe
will not work correctly, on Fission (the patch affects Fission only) - Is this code covered by automated tests?: Yes
- Has the fix been verified in Nightly?: Yes
- Needs manual test from QE?: No
- If yes, steps to reproduce:
- List of other uplifts needed: None
- Risk to taking this patch: Medium
- Why is the change risky/not risky? (and alternatives if risky): This is preventing a method call (thaw) to happen on those browsing context where it is not needed.
- String changes made/needed:
Comment 9•4 years ago
|
||
Comment on attachment 9248070 [details]
Bug 1583110, freeze/thaw in a separate step, r=peterv
Approved for 95 beta 3, thanks.
Comment 10•4 years ago
|
||
| bugherder uplift | ||
Description
•