1767026 - Crash in [@ PrefValue::Deserialize]

Status: RESOLVED WORKSFORME

(Core :: Preferences: Backend, defect)

Description

[Andrew McCreight [:mccr8]]

Maybe Fission related. (DOMFissionEnabled=1)

Crash report: https://crash-stats.mozilla.org/report/index/4f786ecd-391c-4a04-adc8-b8c160220429

Top 9 frames of crashing thread:

0 libxul.so PrefValue::Deserialize modules/libpref/Preferences.cpp:321
1 libxul.so mozilla::Preferences::DeserializePreferences modules/libpref/Preferences.cpp:3661
2 libxul.so mozilla::ipc::ProcessChild::InitPrefs ipc/glue/ProcessChild.cpp:66
3 libxul.so mozilla::RDDProcessImpl::Init dom/media/ipc/RDDProcessImpl.cpp:47
4 libxul.so XRE_InitChildProcess toolkit/xre/nsEmbedFunctions.cpp:695
5 firefox-bin main browser/app/nsBrowserApp.cpp:327
6 libc.so.6 __libc_start_call_main 
7 libc.so.6 __libc_start_main_alias_2 
8 firefox-bin _start 

This is a long-standing issue, but there's a huge spike in this crash on Nightly which is concerning.

Comment 1

[Andrew McCreight [:mccr8]]

Tom, does this correspond to anything related to your prefs work? It looks like it started happening a few days ago, and maybe has gone away in the last few builds.

Comment 2

[Andrew McCreight [:mccr8]]

The large volume of crashes is partly due to individual install times having a ton of crashes, but given the nature of the crash it seems like users are unable to launch new content processes, which means they'll be unable to open any web pages.

Comment 3

[Andrew McCreight [:mccr8]]

I looked at a handful of crashes, and they were all in the "default" case of Deserialize. In other words, PrefType was neither Bool nor Int nor String.

Comment 4

[Andrew McCreight [:mccr8]]

It looks like we call ProcessChild::InitPrefs() before we check the build id, so it is possible that this is a symptom of build mismatch between the parent and child processes, if somehow the format used to send prefs changed. That could explain a high volume of crashes that fell off (after everybody updated their browsers).

Comment 5

[Tom Ritter [:tjr]]

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

It looks like we call ProcessChild::InitPrefs() before we check the build id, so it is possible that this is a symptom of build mismatch between the parent and child processes, if somehow the format used to send prefs changed. That could explain a high volume of crashes that fell off (after everybody updated their browsers).

The format to send prefs absolutely did change, so that might be the culprit...

Comment 6

[Ryan VanderMeulen [:RyanVM]]

We haven't seen a spike on Beta 101, so I guess whatever this was was transitory. Dropping the tracking status as this doesn't look like something to be worrying about at the current rate.

Comment 7

[Andrew McCreight [:mccr8]]

Yeah, this is something that will spike when people upgrade from versions without the pref change to the version with the pref change.

Comment 8

[Ryan VanderMeulen [:RyanVM]]

Yeah, I would have expected to see the spike on Beta as people moved trains from 100->101, but so far it doesn't seem to be happening.

Comment 9

[Ryan VanderMeulen [:RyanVM]]

Is there anything actionable to do in this bug? We never saw a crash spike on 101 when it went to Beta.

Comment 10

[Tom Ritter [:tjr]]

No, I don't think so.

Comment 11

[Gabriele Svelto [:gsvelto]]

There's a significant spike of this happening with 100.2. It looks like it's affecting a few thousand users on Linux and macOS but not on Windows.

Comment 12

[Tom Ritter [:tjr]]

Weird... 100.2 was the pwn2own fix so there's the possibility that it that prompted some community (linux distro?) to do a mass update...