Open Bug 1862348 Opened 2 years ago Updated 2 years ago

Crash in [@ SharedBitSet::test]

Categories

(Core :: Graphics: Text, defect)

x86
Windows 10
defect

Tracking

()

People

(Reporter: release-mgmt-account-bot, Unassigned, NeedInfo)

References

(Blocks 1 open bug)

Details

(Keywords: crash)

Crash Data

Crash report: https://crash-stats.mozilla.org/report/index/db4ab358-8552-44e4-b7b4-115250231003

Reason: EXCEPTION_ACCESS_VIOLATION_READ

Top 10 frames of crashing thread:

0  xul.dll  SharedBitSet::test const  gfx/thebes/gfxFontUtils.h:406
0  xul.dll  gfxFontEntry::HasCharacter  gfx/thebes/gfxFontEntry.h
0  xul.dll  gfxFont::HasCharacter const  gfx/thebes/gfxFont.h:1792
0  xul.dll  gfxFontGroup::GetFirstValidFont::<lambda_0>::operator const  gfx/thebes/gfxTextRun.cpp:2260
0  xul.dll  gfxFontGroup::GetFirstValidFont  gfx/thebes/gfxTextRun.cpp:2271
0  xul.dll  gfxFontGroup::ComputeRanges  gfx/thebes/gfxTextRun.cpp:3432
0  xul.dll  gfxFontGroup::InitScriptRun<char16_t>  gfx/thebes/gfxTextRun.cpp:2711
1  xul.dll  gfxFontGroup::InitTextRun  gfx/thebes/gfxTextRun.cpp:2635
1  xul.dll  gfxFontGroup::MakeTextRun<char16_t>  gfx/thebes/gfxTextRun.cpp:2501
2  xul.dll  BuildTextRunsScanner::BuildTextRunForFrames  layout/generic/nsTextFrame.cpp:2527

By querying Nightly crashes reported within the last 2 months, here are some insights about the signature:

  • First crash report: 2023-09-11
  • Process type: Content
  • Is startup crash: No
  • Has user comments: No
  • Is null crash: No
Component: General → Graphics: Text

I'm not sure what's going on here, but there's a peculiar pattern involved. If you look up the crash address in the registers of each of these crashes you won't find it. Or rather you'll find a register with the upper byte set to 0x91 and the rest matching the crashing address. In other words, this doesn't really look like a pointer, it looks like we tried accessing some data which has the peculiarity of always starting with 0x91.

I forgot to mention something important. The fact that the 0x91 part doesn't show up in the crashing address should be expected, the upper byte is reserved for pointer tagging under AArch64 so it's probably just ignored by the hardware when doing a memory access.

The severity field is not set for this bug.
:lsalzman, could you have a look please?

For more information, please visit BugBot documentation.

Flags: needinfo?(lsalzman)
Severity: -- → S3
Flags: needinfo?(lsalzman) → needinfo?(jfkthame)
You need to log in before you can comment on or make changes to this bug.