1617521 - Fission crash in [@ IPCError-browser | PContent::Msg_PSHistoryConstructor Value error: message was deserialized, but contained an illegal v]

Status: RESOLVED WORKSFORME

(Core :: DOM: Navigation, defect, P5)

Description

[Gabriele Svelto [:gsvelto] (PTO)]

This bug is for crash report bp-12e33210-c88d-4297-ba47-65de00200223.

Top 10 frames of crashing thread:

0 win32u.dll NtUserMsgWaitForMultipleObjectsEx 
1 user32.dll unsigned long RealMsgWaitForMultipleObjectsEx 
2 combase.dll CCliModalLoop::BlockFn onecore\com\combase\dcomrem\callctrl.cxx:2156
3 combase.dll ClassicSTAThreadWaitForHandles onecore\com\combase\dcomrem\classicsta.cpp:51
4 combase.dll CoWaitForMultipleHandles onecore\com\combase\dcomrem\sync.cxx:122
5 xul.dll mozilla::ipc::MessageChannel::WaitForSyncNotifyWithA11yReentry ipc/glue/WindowsMessageLoop.cpp:889
6 xul.dll mozilla::ipc::MessageChannel::Send ipc/glue/MessageChannel.cpp:1567
7 xul.dll mozilla::dom::PSHistoryChild::SendGetAllEntries ipc/ipdl/PSHistoryChild.cpp:1027
8 xul.dll mozilla::dom::SHistoryChild::EvictAllContentViewers docshell/shistory/SHistoryChild.cpp:263
9 xul.dll nsDocShell::Destroy docshell/base/nsDocShell.cpp:4567

New crash first appeared in bug 20200221095110. Seems related to serializing session-history IPC messages, content-process only.

Comment 1

[Andrew McCreight [:mccr8]]

These crashes all have Fission enabled.

Comment 2

[Andrew McCreight [:mccr8]]

Based on comment 0, I think these are the commits that were added in the revision where the crashes started: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b532be9d27193e1572d29f3cf2f9e7b011862081&tochange=acc0c8327c266ac0b0c61eecdba6d625957ecf81

Comment 3

[Andrew McCreight [:mccr8]]

Bug 1615403 and bug 1597154 are the navigation-y things I can see in that commit range. Nika, any ideas? Thanks.

Comment 4

[Andrew McCreight [:mccr8]]

I guess bug 1597154 got backed out, so that can't be it.

Comment 5

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

I don't know how this code is becoming active, as it appears these crashes are coming from the work-in-progress sync parent session history IPC work. I wonder if these individuals have enabled the broken fission.sessionHistoryInParent pref.

:peterv, if they haven't enabled that pref, how could this code be being enabled?

Comment 6

[Peter Van der Beken [:peterv]]

I don't understand how this could happen if they didn't enable fission.sessionHistoryInParent. We explicitly check the pref before creating the SHistoryChild actor (https://searchfox.org/mozilla-central/rev/96f1457323cc598a36f5701f8e67aedaf97acfcf/docshell/shistory/ChildSHistory.cpp#24), so I don't see how we'd create one and then call EvictAllContentViewers on it.
Some of the crashes also seem to have https://hg.mozilla.org/mozilla-central/annotate/28418b02132f1db7d9214f7cb77735fe85bb76cf/docshell/shistory/ChildSHistory.cpp#l121 in the stack trace, which is in a block that's conditional on the pref being set.

Comment 8

[Olli Pettay [:smaug][[e-mail]]]

Doesn't sound super urgent given that this requires one to use unsupported pref.

Comment 11

[Chris Peterson [:cpeterson]]

P5 because user is using unsupported prefs (fission.sessionHistoryInParent). This code will be rewritten as part of Fission's session history in parent work.

Comment 12

[BugBot [:suhaib / :marco/ :calixte]]

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

Comment 13

[BugBot [:suhaib / :marco/ :calixte]]

Closing because no crashes reported for 12 weeks.