Closed Bug 1767026 Opened 2 years ago Closed 2 years ago

Crash in [@ PrefValue::Deserialize]

Categories

(Core :: Preferences: Backend, defect)

Product:
Core
Component:
Preferences: Backend
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
firefox101 - wontfix

People

(Reporter: mccr8, Unassigned)

References

Details

(Keywords: crash, regression)

Crash Data

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.

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.

Flags: needinfo?(tom)

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.

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.

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).

(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...

Flags: needinfo?(tom)

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.

tracking-firefox101: + → -

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

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.

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

Flags: needinfo?(tom)

No, I don't think so.

Status: NEW → RESOLVED
Closed: 2 years ago
Flags: needinfo?(tom)
Resolution: --- → WORKSFORME

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.

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...

You need to log in before you can comment on or make changes to this bug.