1951051 - Crash in [@ __vfscanf_internal] on Raptor Lake CPUs

Status: NEW

(Core :: XPCOM, defect)

Description

[Gabriele Svelto [:gsvelto]]

Crash report: https://crash-stats.mozilla.org/report/index/93a3888f-3bbd-462f-af25-88a3f0250228

Reason:

SIGSEGV / SEGV_MAPERR

Top 10 frames:

0  libc.so.6  __vfscanf_internal  stdio-common/stdio-common/vfscanf-internal.c:3105
1  libc.so.6  __isoc23_sscanf  stdio-common/stdio-common/isoc23_sscanf.c:31
2  libxul.so  mozilla::GetMemoryMappings(nsTArray<mozilla::MemoryMapping>&, int)  build-browser/xpcom/base/xpcom/base/MemoryMapping.cpp:134
3  libxul.so  GetProcSelfSmapsPrivate(long*, int)  build-browser/xpcom/base/xpcom/base/nsMemoryReporterManager.cpp:104
3  libxul.so  ResidentUniqueDistinguishedAmount(long*, int)  build-browser/xpcom/base/xpcom/base/nsMemoryReporterManager.cpp:131
4  libxul.so  mozilla::MemoryTelemetry::GatherReports(std::function<void ()> const&)::$_1::...  build-browser/xpcom/base/xpcom/base/MemoryTelemetry.cpp:348
4  libxul.so  mozilla::detail::RunnableFunction<mozilla::MemoryTelemetry::GatherReports(std...  build-browser/xpcom/base/build-browser/dist/include/nsThreadUtils.h:548
5  libxul.so  nsThreadPool::Run()  build-browser/xpcom/threads/xpcom/threads/nsThreadPool.cpp:456
6  libxul.so  nsThread::ProcessNextEvent(bool, bool*)  build-browser/xpcom/threads/xpcom/threads/nsThread.cpp:1198
7  libxul.so  NS_ProcessNextEvent(nsIThread*, bool)  build-browser/xpcom/threads/xpcom/threads/nsThreadUtils.cpp:480

Dropping this crash in the Telemetry component because that's where it originates but this is 100% a CPU bug and nothing we can do about (save not using sscanf()?). All the crashes are hitting CPUs from the Raptor Lake family, specifically both family 6 model 183 stepping 1 and family 6 model 186 stepping 2 so Raptor Cove P and Raptor Cove S / Gracemont E respectively. All current microcode versions are affected.

Comment 1

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

The bug is linked to a topcrash signature, which matches the following criteria:

• Top 20 desktop browser crashes on beta
• Top 5 desktop browser crashes on Linux on beta

:nika, could you consider increasing the severity of this top-crash bug?

For more information, please visit BugBot documentation.

Comment 2

[Gabriele Svelto [:gsvelto]]

Not much we can do here. The latest microcode version (0x12c) is still affected.

Comment 3

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

Based on the topcrash criteria, the crash signature linked to this bug is not a topcrash signature anymore.

For more information, please visit BugBot documentation.

Comment 4

[Michal Dominiak]

This is currently making firefox basically unusable for me, which is doubly annoying since chrome is unusable in general now with the adblock apocalypse.

Any chance firefox could either stop calling into this exact path in this function - or maybe provide some sort of a flag to avoid whatever functionality it is that needs to scan the process' mmaps?

...literally got this crash again before I was able to finish submitting this comment. Sigh.

Comment 5

[Gabriele Svelto [:gsvelto]]

This is called as part of a legacy telemetry ping IIUC. One way to avoid it is to turn off telemetry, check out this article. See if that helps.