Open Bug 1578430 Opened 5 years ago Updated 1 year ago

Crash in [@ mozilla::StaticPrefs::InitStaticPrefsFromShared]

Categories

(Core :: Preferences: Backend, defect, P2)

defect

Tracking

()

Tracking Status
firefox-esr60 --- unaffected
firefox-esr68 --- unaffected
firefox69 --- unaffected
firefox70 --- wontfix
firefox71 --- fix-optional

People

(Reporter: marcia, Unassigned)

References

Details

(Keywords: crash, regression)

Crash Data

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

This bug is for crash report bp-7155c1a1-e483-404c-84ee-facc60190814.

Spinning this off from the original cloned bug, since per Bug 1573731#c26 there are still crashes on all platforms that aren't related to the diagnostic assert.

Here is part of that comment for reference:

-603 of them do not involve the diagnostic assert, e.g. Windows, Linux, Mac. These have continued.

The non-diagnostic-assert ones have a crash address and crash reason field that is consistent with a diagnostic assert (e.g. 0x7ffd697135c7 and EXCEPTION_BREAKPOINT on Windows; 0 and SIGSEGV on Linux), but lack a "MOZ_CRASH Reason (Raw)" field. I can't see what code remaining within InitStaticPrefsFromShared() could cause crashes like these.

Top 10 frames of crashing thread:

0 xul.dll mozilla::StaticPrefs::InitStaticPrefsFromShared obj-firefox/dist/include/mozilla/StaticPrefList_dom.h:1286
1 xul.dll mozilla::ipc::SharedPreferenceDeserializer::DeserializeFromSharedMemory ipc/glue/ProcessUtils_common.cpp:176
2 xul.dll mozilla::dom::ContentProcess::Init dom/ipc/ContentProcess.cpp:174
3 xul.dll XRE_InitChildProcess toolkit/xre/nsEmbedFunctions.cpp:739
4 firefox.exe static int content_process_main ipc/contentproc/plugin-container.cpp:56
5 firefox.exe static int NS_internal_main browser/app/nsBrowserApp.cpp:267
6 firefox.exe wmain toolkit/xre/nsWindowsWMain.cpp:131
7 firefox.exe static int __scrt_common_main_seh f:/dd/vctools/crt/vcstartup/src/startup/exe_common.inl:288
8 kernel32.dll BaseThreadInitThunk 
9 ntdll.dll RtlUserThreadStart 

Fixing some of the hyperlinking that got lost in comment #0: the original is bug 1573731 comment #26, and the example crash reports are:

I don't think there's any evidence that this is IPC, but there isn't a lot of actionable information in the crash reports in any case.

Component: IPC → Preferences: Backend
Priority: P1 → --

Some notable things:

  • Bug 1573731 comment 29 says that metadata for "minimal info" crashes is unreliable, and may be synthesized using metadata from a different version of Firefox than the version on which the crash happened. All of these crashes are "minimal info" ones.
  • The crash rate is trending downward strongly.
  • The crashes are still Nightly only.

I suspect that the remaining crashes are just manifestations of the diagnostic assert crash that I fixed in bug 1573731, and that the one that are still coming in are either because (a) some people are slow in letting their Nightly update (I often ignore the prompts to update for a couple of days, I'm sure others do too), or (b) there is some delay in sending in the synthesized crashes. If I'm right about this, the crash rate will naturally trend down to zero over time.

QA Whiteboard: qa-not-actionable
Severity: critical → S2

Since the crash volume is low (less than 15 per week), the severity is downgraded to S3. Feel free to change it back if you think the bug is still critical.

For more information, please visit auto_nag documentation.

Severity: S2 → S3
You need to log in before you can comment on or make changes to this bug.