1616081 - Crash in [@ mozilla::ipc::IPDLParamTraits<T>::Read] (Attempt to deserialize absent BrowsingContext)

Status: RESOLVED DUPLICATE of bug 1615403

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

Description

[[:philipp]]

[Tracking Requested - why for this release]:

+++ This bug was initially created as a clone of Bug #1603976 +++

This bug is for crash report bp-c68f66f2-c1fb-4264-a324-2c1ba0200217.

Top 10 frames of crashing thread:

0 xul.dll static mozilla::ipc::IPDLParamTraits<mozilla::dom::BrowsingContext*>::Read docshell/base/BrowsingContext.cpp:1554
1 xul.dll mozilla::dom::PContentParent::OnMessageReceived ipc/ipdl/PContentParent.cpp:11559
2 xul.dll mozilla::ipc::MessageChannel::DispatchMessage ipc/glue/MessageChannel.cpp:2137
3 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1220
4 xul.dll NS_ProcessNextEvent xpcom/threads/nsThreadUtils.cpp:486
5 xul.dll mozilla::ipc::MessagePump::Run ipc/glue/MessagePump.cpp:109
6 xul.dll MessageLoop::RunHandler ipc/chromium/src/base/message_loop.cc:308
7 xul.dll MessageLoop::Run ipc/chromium/src/base/message_loop.cc:290
8 xul.dll nsBaseAppShell::Run widget/nsBaseAppShell.cpp:137
9 xul.dll nsAppShell::Run widget/windows/nsAppShell.cpp:406

I'm filing this bug as a clone of bug 1603976, since we still see the crash signature with MOZ_CRASH(Attempt to deserialize absent BrowsingContext) quite frequently after firefox 74 went out to the beta user base - the crash is currently accounting for 2.7% of browser crashes in 74.0b3.

the crashes on beta are taking place across all platforms and commonly reported urls are icefilms.info and twitch.tv.

Comment 1

[Jens Stutte [:jstutte]]

I see a note before the MOZ_CRASH introduced with bug 1563604 that reads:

    // NOTE: We could fail softly by returning `false` if the `BrowsingContext`
    // isn't present, but doing so will cause a crash anyway. Let's improve
    // diagnostics by reliably crashing here.
    //
    // If we can recover from failures to deserialize in the future, this crash
    // should be removed or modified.

Nika, are we in the better future the note is waiting for? Can we diagnose something new or better now?

Comment 2

[Jens Stutte [:jstutte]]

Note that there are very few crashes with a different origin, as far as I can see those under Windows that have Crash Address in {0xffffffffffffffff, 0x0, 0x1}. Not sure if it is worth to sort them out - but if we keep/ignore the MOZ_CRASH(Attempt to deserialize absent BrowsingContext) probably yes.

Comment 3

[Pascal Chevrel:pascalc]

The volume of crashes is very concerning on Beta, marking as blocker for the 74 release.

Comment 4

[Jens Stutte [:jstutte]]

This is different from bug 1603976. Here we have a CommitBrowsingContextTransaction message. Seems related to docshell. So the component changes.

Comment 5

[Nika Layzell [:nika] (ni? for response)]

This entire class of crashes will be removed with the changes in bug 1615403, but a patch of that scale may not be appropriate to uplift to Beta.

(In reply to Jens Stutte [:jstutte] from comment #1)

Nika, are we in the better future the note is waiting for? Can we diagnose something new or better now?

Unfortunately no, and returning false here will lead to a crash as well, but in a different place in the code :-/

Comment 6

[Nika Layzell [:nika] (ni? for response)]

:kmag, I think your changes from bug 1582832 are probably the largest changes to BrowsingContext's lifetimes which have occurred in the 74 cycle, which forked about a week ago. This crash is caused by the BrowsingContext object not existing in the parent process when it receives a message, despite the BrowsingContext not being marked as discarded in the content process. Is there any chance you've fixed a bug which could cause this sometime during the last week?

Comment 7

[Chris Peterson [:cpeterson]]

Tracking for Fission dogfooding (M5). Even if this BrowsingContext crash is not Fission-specific, it is related to stability of Fission work.

Comment 8

[Chris Peterson [:cpeterson]]

@ kmag or Nika, can this BrowsingContext crash only happen when DocumentChannel is enabled? Should fixing this crash be considered a blocker for DocumentChannel riding to 74 Release?

P1 because this is top crash #3 in 74 Beta. We should definitely uplift this fix to Beta.

75 Nightly appears to be unaffected. There is only one crash report with a matching signature from 75 Nightly so far, but it's an EXCEPTION_ACCESS_VIOLATION_READ with a slightly different stack trace, not a MOZ_CRASH(Attempt to deserialize absent BrowsingContext).

Comment 9

[Jens Stutte [:jstutte]]

(In reply to :Nika Layzell (ni? for response) from comment #5)

This entire class of crashes will be removed with the changes in bug 1615403, but a patch of that scale may not be appropriate to uplift to Beta.

Is it ready? If it solves this and other issues, it might be the faster lane? I understand the concerns - do we have a good test coverage (from fuzzers) for this?

Comment 10

[Randell Jesup [:jesup] (needinfo me)]

Chris, can you help find an assignee for this; it's a 74 blocker. (IIRC there may be a patch that could be uplifted?)

Comment 11

[Chris Peterson [:cpeterson]]

(In reply to :Nika Layzell (ni? for response) from comment #6)

:kmag, I think your changes from bug 1582832 are probably the largest changes to BrowsingContext's lifetimes which have occurred in the 74 cycle, which forked about a week ago. This crash is caused by the BrowsingContext object not existing in the parent process when it receives a message, despite the BrowsingContext not being marked as discarded in the content process. Is there any chance you've fixed a bug which could cause this sometime during the last week?

Tentatively assigning to kmag because Nika suspects kmag may have already fixed this bug in 75 Nightly.

Comment 12

[Andrew Overholt [:overholt]]

(In reply to :Nika Layzell (ni? for response) from comment #6)

:kmag, I think your changes from bug 1582832 are probably the largest changes to BrowsingContext's lifetimes which have occurred in the 74 cycle, which forked about a week ago. This crash is caused by the BrowsingContext object not existing in the parent process when it receives a message, despite the BrowsingContext not being marked as discarded in the content process. Is there any chance you've fixed a bug which could cause this sometime during the last week?

The patches in bug 1582832 were just backed out from beta today so I guess we'll see a decrease in crash volume here soon? How long should we wait before declaring things ok?

Comment 13

[Andrew Overholt [:overholt]]

(kmag reminded me that we also need to confirm that the changes in bug 1582832 were the actual cause here)

Comment 14

[Pascal Chevrel:pascalc]

One crash only in 74.0b6 after the backout of bug 1582832 and no crash on nightly, marking this crash as fixed by the backout.

Comment 15

[Chris Peterson [:cpeterson]]

Moving P1 M5 bugs to M5a milestone

Comment 16

[Nika Layzell [:nika] (ni? for response)]

This crash no longer exists since bug 1615403 has landed.

Comment 17

[Firefox Bug Husbandry Bot]

Please specify a root cause for this bug. See :tmaity for more information.