After some hours I clicked on the green message in the main menu to apply an update and instead of restarting, a crash reporter popped up.

This bug is for crash report bp-d07bcfcf-e504-4687-954f-9544a0191214.

MOZ_CRASH(Attempt to deserialize absent BrowsingContext)

Top 10 frames of crashing thread:

0 libxul.so mozilla::ipc::IPDLParamTraits<mozilla::dom::BrowsingContext*>::Read docshell/base/BrowsingContext.cpp:1510
1 libxul.so mozilla::dom::PContentParent::OnMessageReceived ipc/ipdl/PContentParent.cpp:12005
2 libxul.so mozilla::ipc::MessageChannel::DispatchMessage ipc/glue/MessageChannel.cpp:2209
3 libxul.so mozilla::ipc::MessageChannel::RunMessage ipc/glue/MessageChannel.cpp:1973
4 libxul.so nsThread::ProcessNextEvent ipc/glue/MessageChannel.cpp:2004
5 libxul.so <name omitted> xpcom/threads/nsThreadUtils.cpp:486
6 libxul.so mozilla::ipc::MessagePump::Run ipc/glue/MessagePump.cpp:87
7 libxul.so MessageLoop::Run ipc/chromium/src/base/message_loop.cc:290
8 libxul.so nsBaseAppShell::Run widget/nsBaseAppShell.cpp:137
9 libxul.so nsAppStartup::Run toolkit/components/startup/nsAppStartup.cpp:272

This crash spiked. It looks like there was a regression between build 20191213094653 (0 crashes) and 20191213214322 (39 crashes/22 installs):
https://hg.mozilla.org/mozilla-central/firefoxreleases#d1ac49b9eb3enightlylinux6420191213094653
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=d1ac49b9eb3efcc46210bb7ad810c80ba74f7dd7&tochange=f09f24f2b545919ab0db4bd352c276779c58bcc6

Bug 1596784 landed in that timeframe. ni on :jesup

(In reply to Jan Andre Ikenmeyer [:darkspirit] from comment #0)

After some hours I clicked on the green message in the main menu to apply an update and instead of restarting, a crash reporter popped up.

I've hit this crash a few times, and it was in the same circumstance.

Given the unusually high volume on nightly, this is a blocking issue.

This is not a Fission-specific bug (only 22% of these crash reports have Fission enabled), though Fission does seem to exacerbate this crash signature. Less than 4% of other Nightly crashes have Fission enabled.

Correction: This crash is Fission-specific. Andrew points out (in comment 9 below) that the crash reports with this signature and reason "Attempt to deserialize absent BrowsingContext" are all Fission.

I looked at 5 of these crashes, and they were all crashing during deserialization of the first argument to the PContent::SessionStorageData message. Two of them were happening when we're in XPCOM shutdown, doing "profile-before-change", but the others weren't.

Bug 1593246 is in the regression range in comment 0, and it looks like it added calls to SessionStorageData. Jan, maybe you could take a look, with Yaron out on PTO? Thanks.

SessionStorageManager::SendSessionStorageDataToParentProcess() does guard against the BC being discarded, so we're not hitting any assert on the sending side. Maybe there's some kind of race where the BC goes away entirely in the parent before it is discarded in the child?

(In reply to Chris Peterson [:cpeterson] from comment #5)

This is not a Fission-specific bug (only 22% of these crash reports have Fission enabled), though Fission does seem to exacerbate this crash signature. Less than 4% of other Nightly crashes have Fission enabled.

Unfortunately [@ mozilla::ipc::IPDLParamTraits<T>::Read ] is a pretty generic signature (which we should improve by adding something to the prefix or skip list, though I don't know how much that will help). If I search for crashes where the crash reason contains "Attempt to deserialize absent BrowsingContext", then 100% of them have Fission enabled. I looked at a few of the ones with that Read thing as a signature that didn't have Fission enabled, and they looked different. So I'd say this particular crash is Fission-specific.

If this is Fission-only, we don't need to track this for 73.

This crash can also be triggered just by closing tabs.

Currently the #2 overall signature on 73 nightly.

This signature is still rather highly on nightly - can we get an update on where we are next week?

Looking.

I'm creating a Pernosco session with a suitable scenario to better understand how shutdown interacts with session storage. Once it's ready I'll try to figure out how the BrowsingContext can disappear in the parent before the session storage data is received.

:darkspirit, you mentioned it's possible to trigger this by closing tabs; how often can you reproduce this? Does it happen more often in particular websites? So far I didn't manage to reproduce the crash.

Last crash so far was on 2019-12-30: bp-eb863b44-11f3-4a63-b628-057d70191230
Crashing tabs was only possible if I had many inactive tabs and tried to close them by Ctrl+W. The crash happened after closing about 4 tabs or so.

Last crash so far was on 2019-12-30: bp-eb863b44-11f3-4a63-b628-057d70191230

Ha, I should reenable fission... ;)

[Tracking Requested - why for this release]: This is a Fission-only crash, so I don't think it needs to be tracked for Firefox 74. (There are crashes with this signature on other branches, but they are different issues.)

(In reply to Yaron Tausky [:ytausky] from comment #16)

:darkspirit, you mentioned it's possible to trigger this by closing tabs; how often can you reproduce this? Does it happen more often in particular websites? So far I didn't manage to reproduce the crash.

I hit this crash 3-4 times a day, but I don't have reliable STR. The crash seems to often happen when I'm switching from Firefox to another application. I have many Google Docs tabs open and sometimes a long-running YouTube tab playing.

Socorro Super Search shows a bunch of random URLs, including about:newtab but also some YouTube and Twitch URLs:

https://crash-stats.mozilla.org/search/?dom_fission_enabled=%21__null__&signature=~mozilla%3A%3Aipc%3A%3AIPDLParamTraits%3CT%3E%3A%3ARead&product=Firefox&version=73.0a1&date=%3E%3D2019-12-24T18%3A49%3A00.000Z&date=%3C2020-01-07T18%3A49%3A00.000Z&_facets=signature&_facets=url&_sort=-date&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-url

Under some (yet) unclear conditions it's possible for a content
process to send session storage data for a browsing context that's
already been discarded. This leads to an assertion failure when
deserializing the IPC message. This commit works around this issue
by sending the browsing context's ID over IPC and issuing a warning
instead of asserting that the browsing context still exists.

I'm landing a workaround patch that should stop the crashes, but marking the bug leave-open to investigate why this situation occurs at all.

We have some other bugs filed about things getting discarded at the wrong time, so maybe this is related to that? kmag has patches up for review in bug 1582832, so maybe those will improve the situation.

https://hg.mozilla.org/mozilla-central/rev/2616040b2fc8

It looks like the patch did make this crash go away, so I suppose it is more "fixed" than "disabled".

It's still unclear why the crash happened in the first place, but I don't think we'll get to the bottom of this now. Therefore closing.