1780984 - Crash in [@ OT::OffsetTo<T>::sanitize<T>]

Status: RESOLVED WORKSFORME

(Core :: Graphics: Text, defect)

Description

[Andrew Osmond [:aosmond] (he/him)]

Volume seems to have gone up in nightly. Always seems to be on the main thread but I wonder if it could be related to the recent font changes for OffscreenCanvas?

--

Crash report: https://crash-stats.mozilla.org/report/index/a47255d3-e99b-4ae6-9659-8ce3c0220723

Reason: EXCEPTION_IN_PAGE_ERROR_READ / STATUS_DEVICE_DATA_ERROR

Top 10 frames of crashing thread:

0 xul.dll OT::OffsetTo<OT::Layout::GPOS_impl::Anchor, OT::IntType<unsigned short, 2>, 1>::sanitize<> const gfx/harfbuzz/src/hb-open-type.hh:412
1 xul.dll OT::ArrayOf<OT::Layout::GPOS_impl::MarkRecord, OT::IntType<unsigned short, 2> >::sanitize<const OT::Layout::GPOS_impl::MarkArray*> const gfx/harfbuzz/src/hb-open-type.hh:714
2 xul.dll OT::GSUBGPOS::sanitize<OT::Layout::GPOS_impl::PosLookup> const gfx/harfbuzz/src/hb-ot-layout-gsubgpos.hh:4129
3 xul.dll OT::GSUBGPOS::accelerator_t<OT::Layout::GPOS>::accelerator_t gfx/harfbuzz/src/hb-ot-layout-gsubgpos.hh:4149
4 xul.dll hb_ot_layout_has_positioning gfx/harfbuzz/src/hb-ot-layout.cc:1570
5 xul.dll gfxFont::CheckForFeaturesInvolvingSpace const gfx/thebes/gfxFont.cpp:1368
6 xul.dll gfxFont::SplitAndInitTextRun<char16_t> gfx/thebes/gfxFont.cpp:3302
7 xul.dll gfxFontGroup::InitScriptRun<char16_t> gfx/thebes/gfxTextRun.cpp:2741
8 xul.dll gfxFontGroup::MakeTextRun gfx/thebes/gfxTextRun.cpp:2524
9 xul.dll nsFontMetrics::GetWidth gfx/src/nsFontMetrics.cpp:299

Comment 1

[Jonathan Kew [:jfkthame]]

This crash shows EXCEPTION_IN_PAGE_ERROR_READ / STATUS_DEVICE_DATA_ERROR, which sounds like an i/o failure accessing a font file; there are a steady stream of such crashes, with various stacks depending exactly which part of the code was trying to access the font. Some of these happen directly in our code (e.g. when harfbuzz wants to read a font table, as here), and others are from deep inside system libraries (e.g. when DirectWrite is trying to rasterize a glyph), but I suspect they're all the same underlying cause (or causes)... maybe things like bad sectors, flaky USB drives, network drive access problems, ...???

I doubt this is related to the recent font changes; I think it's a longstanding problem that any i/o operations can throw exceptions, and we don't always catch/handle these. A search for https://crash-stats.mozilla.org/search/?reason=~EXCEPTION_IN_PAGE_ERROR_READ shows a wide variety of such crashes, a good number of them in font-related code (because we access lots of font files, so if there's disk access flakiness there's good chance that's where we'll encounter it) but also others that look like they may be accessing files in the profile, etc.

Comment 2

[Andrew Osmond [:aosmond] (he/him)]

If you filter by nightly, you will see it spiked in 104, whereas before we never observed it in nightly, only release. We need to watch this carefully in beta because this could blow up.

Comment 3

[Jonathan Kew [:jfkthame]]

Yes, let's keep an eye on it. For now, I looked at several of the reports from the nightly "spike", and it looks to me like they're probably all from the same machine.

Comment 4

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

Closing because no crashes reported for 12 weeks.