Closed Bug 1590048 Opened 3 months ago Closed 2 months ago

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

Categories

(Core :: DOM: Navigation, defect, P2, critical)

Unspecified
Windows 10
defect

Tracking

()

RESOLVED DUPLICATE of bug 1580194
Fission Milestone M5

People

(Reporter: gsvelto, Unassigned)

References

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

Details

(Keywords: crash, regression)

Crash Data

This bug is for crash report bp-4b925c1d-61bd-49c8-9490-f7b240191020.

Top 10 frames of crashing thread:

0 xul.dll mozilla::dom::BrowsingContext::Get docshell/base/BrowsingContext.cpp:89
1 xul.dll mozilla::dom::BrowsingContext::GetOpener docshell/base/BrowsingContext.h:225
2 xul.dll nsGlobalWindowOuter::TabGroupOuter dom/base/nsGlobalWindowOuter.cpp:7714
3 xul.dll nsGlobalWindowOuter::TabGroupOuter dom/base/nsGlobalWindowOuter.cpp
4 xul.dll nsGlobalWindowOuter::TabGroupOuter dom/base/nsGlobalWindowOuter.cpp
5 xul.dll nsGlobalWindowOuter::TabGroupOuter dom/base/nsGlobalWindowOuter.cpp
6 xul.dll nsGlobalWindowOuter::TabGroupOuter dom/base/nsGlobalWindowOuter.cpp
7 xul.dll nsGlobalWindowOuter::TabGroupOuter dom/base/nsGlobalWindowOuter.cpp
8 xul.dll nsGlobalWindowOuter::TabGroupOuter dom/base/nsGlobalWindowOuter.cpp
9 xul.dll nsGlobalWindowOuter::TabGroupOuter dom/base/nsGlobalWindowOuter.cpp

This is a stack overflow caused by excessive (infinite?) recursion in nsGlobalWindowOuter::TabGroupOuter(). This could be a regression as it happens only on nightly and the oldest build for which I could find a crash is 20190916155843.

A quick glance at the crashes shows that most of them have a few addons installed.

Bugbug thinks this bug is a regression, but please revert this change in case of error.

Keywords: regression

These crashes all have Fission enabled.

Flags: needinfo?(nika)

Interesting. I'm guessing that the window window.open-ed itself, meaning it's opener is set to itself, and then changed process. The TabGroup code doesn't handle process switches well, and so bugs out when in this state.

This should be fixed by removing the mechanism entirely in bug 1561715, though may also be possible to work around if that isn't going to be happening super soon.

Flags: needinfo?(nika)
Duplicate of this bug: 1592403

Bug 1592403 has some STR for this infinite recursion.

Crash Signature: [@ mozilla::dom::BrowsingContext::Get] → [@ mozilla::dom::BrowsingContext::Get] [@ nsDocShell::QueryInterface]

Because of removal of TabGroup possibly fixing this, perhaps farre you could retest this stuff (using Bug 1592403) after TabGroups are gone.

Crash Signature: [@ mozilla::dom::BrowsingContext::Get] [@ nsDocShell::QueryInterface] → [@ mozilla::dom::BrowsingContext::Get] [@ nsDocShell::QueryInterface]
Flags: needinfo?(afarre)
Priority: -- → P3

Tentatively moving all bugs whose summaries mention "Fission" (or other Fission-related keywords) but are not assigned to a Fission Milestone to the "?" triage milestone.

This will generate a lot of bugmail, so you can filter your bugmail for the following UUID and delete them en masse:

0ee3c76a-bc79-4eb2-8d12-05dc0b68e732

Fission Milestone: --- → ?
Fission Milestone: ? → M5
Priority: P3 → P2

Andreas confirmed that this depends on TabGroup removal.

Depends on: 1561715
Flags: needinfo?(afarre)
Status: NEW → RESOLVED
Closed: 2 months ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1580194
You need to log in before you can comment on or make changes to this bug.