Closed Bug 1560110 Opened 7 months ago Closed 4 months ago

[Fission] Crash in [@ mozilla::dom::BrowsingContextGroup::EnsureSubscribed]

Categories

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

69 Branch
defect

Tracking

()

VERIFIED FIXED
mozilla71
Fission Milestone M4
Tracking Status
firefox-esr60 --- unaffected
firefox-esr68 --- unaffected
firefox67 --- unaffected
firefox67.0.1 --- unaffected
firefox68 --- unaffected
firefox69 --- disabled
firefox70 --- disabled
firefox71 --- verified
firefox72 --- verified

People

(Reporter: emilghitta, Assigned: farre)

References

(Blocks 4 open bugs, Regressed 1 open bug, Regression)

Details

(Keywords: crash, regression)

Crash Data

Attachments

(2 files)

This bug is for crash report bp-aad634e7-bdd7-4d14-9254-262f10190619.

Top 10 frames of crashing thread:

0 xul.dll mozilla::dom::BrowsingContextGroup::EnsureSubscribed docshell/base/BrowsingContextGroup.cpp:76
1 xul.dll nsresult mozilla::dom::BrowserBridgeParent::Init dom/ipc/BrowserBridgeParent.cpp:63
2 xul.dll mozilla::dom::BrowserParent::RecvPBrowserBridgeConstructor dom/ipc/BrowserParent.cpp:1246
3 xul.dll mozilla::dom::PBrowserParent::OnMessageReceived ipc/ipdl/PBrowserParent.cpp:2863
4 xul.dll mozilla::dom::PContentParent::OnMessageReceived ipc/ipdl/PContentParent.cpp:5576
5 xul.dll mozilla::ipc::MessageChannel::DispatchMessage ipc/glue/MessageChannel.cpp:2082
6 xul.dll mozilla::ipc::MessageChannel::MessageTask::Run ipc/glue/MessageChannel.cpp:1970
7 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1225
8 xul.dll NS_ProcessNextEvent xpcom/threads/nsThreadUtils.cpp:486
9 xul.dll void mozilla::ipc::MessagePump::Run ipc/glue/MessagePump.cpp:88

Affected Versions:

  • Firefox 69.0a1 (BuildId:20190618214619).

Affected Platforms:

  • Windows 10 64bit.
  • Windows 7 64bit.

Steps to Reproduce:

  1. Launch Firefox with a clean profile.
  2. Access the about:config page.
  3. Create the fission.autostart pref and set it to true.
  4. Access the facebook.com webpage.
  5. Log in with valid credentials.

Expected Result:

  • The website is successfully displayed and Firefox is stable.

Actual Result:

  • Firefox Crashes.
Blocks: improve-bc
No longer blocks: fission
Fission Milestone: --- → M4
Component: General → Document Navigation
Priority: -- → P2
Flags: needinfo?(afarre)

And this is also because of Bug 1555287.

Assignee: nobody → afarre
Status: NEW → RESOLVED
Closed: 7 months ago
Flags: needinfo?(afarre)
Regressed by: 1559537
Resolution: --- → FIXED
No longer regressed by: 1559537
Regressed by: 1555287

Reopening since I got this crash on buildid:20190629100032 with enabling fission. bp-91f41329-f620-4f90-bb0a-301b20190629

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

Updating 70 as affected. I saw this signature in the nightly triage. We are still getting crashes on 70 but most appear to be single installation crashes.

(In reply to Marcia Knous [:marcia - needinfo? me] from comment #3)

Updating 70 as affected. I saw this signature in the nightly triage. We are still getting crashes on 70 but most appear to be single installation crashes.

Marcia, did you see Fission enabled on these signatures? Until bug 1563317 is fixed, we cannot search for it, but I think you can.

Flags: needinfo?(mozillamarcia.knous)

(In reply to Neha Kochar [:neha] from comment #4)

(In reply to Marcia Knous [:marcia - needinfo? me] from comment #3)

Updating 70 as affected. I saw this signature in the nightly triage. We are still getting crashes on 70 but most appear to be single installation crashes.

Marcia, did you see Fission enabled on these signatures? Until bug 1563317 is fixed, we cannot search for it, but I think you can.

All of these crashes have this correlation: (100.0% in signature vs 00.05% overall) moz_crash_reason = MOZ_RELEASE_ASSERT(inits.Length() == mContexts.Count()) (Visited the wrong number of contexts!)

I am not sure if that is what I am supposed to see when Fission is enabled - I couldn't find anything in Bug 1560977 which stated exactly what the correlation will say.

Flags: needinfo?(mozillamarcia.knous)

(In reply to Marcia Knous [:marcia - needinfo? me] from comment #5)

I am not sure if that is what I am supposed to see when Fission is enabled - I couldn't find anything in Bug 1560977 which stated exactly what the correlation will say.

Under the Metadata tab, the crash report will have DOMFissionEnabled = 1 if Fission is enabled.

I looked at reports from 5 different install times, and they all had Fission enabled.

(In reply to Andrew McCreight [:mccr8] from comment #6)

(In reply to Marcia Knous [:marcia - needinfo? me] from comment #5)

I am not sure if that is what I am supposed to see when Fission is enabled - I couldn't find anything in Bug 1560977 which stated exactly what the correlation will say.

Under the Metadata tab, the crash report will have DOMFissionEnabled = 1 if Fission is enabled.

I looked at reports from 5 different install times, and they all had Fission enabled.

Thanks for the confirmation, Andrew.

Fission Milestone: M4 → M5
Priority: P2 → P3

Changing platform to all since I see Mac and Linux crashes as well in nightly triage.

OS: Windows → All

Low volume crash, marking fix-optional to remove this from weekly triage.

This signature is also seen in mochitests-fission failures.

Fission Milestone: M5 → M4
Duplicate of this bug: 1571698
Crash Signature: [@ mozilla::dom::BrowsingContextGroup::EnsureSubscribed] → [@ mozilla::dom::BrowsingContextGroup::EnsureSubscribed] [@ mozilla::dom::BrowsingContextGroup::EnsureSubscribed(mozilla::dom::ContentParent*)]

NI'ing farre to look into this as this is also seen in M-fis failures (bug 1571698).

Crash Signature: [@ mozilla::dom::BrowsingContextGroup::EnsureSubscribed] [@ mozilla::dom::BrowsingContextGroup::EnsureSubscribed(mozilla::dom::ContentParent*)] → [@ mozilla::dom::BrowsingContextGroup::EnsureSubscribed] [@ mozilla::dom::BrowsingContextGroup::EnsureSubscribed(mozilla::dom::ContentParent*)]
Flags: needinfo?(afarre)

To be able to reach all BrowsingContexts in
BrowsingContextGroup::EnsureSubscribed we need to make sure that if a
BrowsingContext is detached, we need to cache all of its children in
case we call BrowsingContextGroup::EnsureSubscribed before the
children in turn are detached.

Pushed by afarre@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/ccfb50e42937
Cache children of detached browsing contexts. r=nika
https://hg.mozilla.org/integration/autoland/rev/0e84d46d732a
Remove skip-ifs for tests. r=kmag
Status: REOPENED → RESOLVED
Closed: 7 months ago4 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla71
Regressions: 1580565
Flags: needinfo?(afarre)
Flags: qe-verify+

Hello,

Confirming this issue as verified fixed on 71.0a1(20190912094122) and 72.0a1 (BuildID:20191103213857). Verified on Windows 10x64, macOS 10.14 and Ubuntu 18.04.

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