1838808 - Crash in [@ mozilla::gfx::GeneralPattern::GetPattern] caused by potential bug in Zen 2 Matisse CPUs

Status: NEW

(Core :: Graphics, defect)

Description

[Gabriele Svelto [:gsvelto]]

Crash report: https://crash-stats.mozilla.org/report/index/b10f7961-6900-4c3f-a067-13a660230513

Reason: EXCEPTION_ACCESS_VIOLATION_READ

Top 10 frames of crashing thread:

0  xul.dll  mozilla::gfx::GeneralPattern::GetPattern  gfx/2d/PatternHelpers.h:116
0  xul.dll  gfxPattern::GetSolidColor  gfx/thebes/gfxPattern.cpp:197
0  xul.dll  gfxContext::GetDeviceColor const  gfx/thebes/gfxContext.cpp:388
0  xul.dll  gfxContext::HasNonOpaqueNonTransparentColor const  gfx/thebes/gfxContext.h:352
0  xul.dll  gfxTextRun::Draw const  gfx/thebes/gfxTextRun.cpp:598
1  xul.dll  DrawTextRun  layout/generic/nsTextFrame.cpp:6588
1  xul.dll  nsTextFrame::DrawTextRun  layout/generic/nsTextFrame.cpp:6597
1  xul.dll  nsTextFrame::DrawText  layout/generic/nsTextFrame.cpp:6837
2  xul.dll  nsTextFrame::PaintText  layout/generic/nsTextFrame.cpp:6521
3  xul.dll  mozilla::nsDisplayText::RenderToContext  layout/painting/nsDisplayList.cpp:7652

This is one weird crash. It happens consistently over several versions of Firefox but affects only users with Zen 2 Matisse CPUs (and not other Zen 2 variants). It seems unlikely to be actionable but I'm filing it so we can track it.

Comment 1

[Jeff Muizelaar [:jrmuizel]]

Paul, any idea what might be going on here?

Comment 2

[Paul Blinzer]

Not yet. I will need to have a more detailed look on the crash dump, at first look there's nothing actionable.
@gsvelto, I assume the system has all the latest Firmware and AMD drivers installed (chipset and graphics) from support.amd.com? Can you please provide the systeminfo of that PC ?
How often does it repro? and does it repro with an AMD GPU too (since this is apparently a NVidia discrete in the system and the crash seems related to graphics)?

Comment 3

[Gabriele Svelto [:gsvelto]]

We have crashes on file with both AMD and NVidia GPUs. We can't check the AMD chipset driver versions since we don't have that bit of information in the crash reports, however we know the microcode versions of the crashes. This is the distribution:

 1 	0x8701021 	35 	43.75 %
2 	0x8701013 	26 	32.50 %
3 	0x8701030 	11 	13.75 %
4 	0x8701012 	3 	3.75 %
5 	0x8600104 	1 	1.25 %
6 	0x8608103 	1 	1.25 %
7 	0x8701002 	1 	1.25 %

0x8701030 should be the latest version of the microcode available for this particular CPU, right?

Comment 4

[Paul Blinzer]

This took a little to research internally but it turns out that the Firmware or chipset driver version and the CPU microcode version are not necessarily aligned between different OEM Firmware releases and the chipset drivers. Insofar, it is not possible to identify what chipset driver is loaded from the microcode version, as the chipset driver solution will not change the microcode version and the Firmware change (which is the preferred solution if available from the OEM) doesn't affect the microcode version either.

Therefore one would have to get the chipset driver version or the Firmware/AGESA version number to identify the presence of the fix.
Given the failure pattern and the knowledge that updated chipset drivers or Firmware address that problem, I would expect the systems still failing do not have an updated firmware or chipset drivers installed. But without the appropriate component version this is hard to confirm.