1895636 - Crash in [@ (anonymous namespace)::_Minmax_element<T>] from ots::OpenTypeGLYF::Parse

Status: NEW

(Core :: Graphics: Text, defect)

Description

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

Crash report: https://crash-stats.mozilla.org/report/index/ad6cc9a0-87f4-448f-9261-b49c30240507

Reason: EXCEPTION_ACCESS_VIOLATION_READ

Top 10 frames of crashing thread:

0  xul.dll    /builds/worker/workspace/obj-build/toolkit/library/build/D:/a/_work/1/s/src/vctools/crt/github/stl/src/vector_algorithms.cpp:971
1  xul.dll  __std_max_element  /builds/worker/fetches/vs/VC/Tools/MSVC/14.39.33519/include/xutility:182
1  xul.dll  std::_Max_element_unchecked  /builds/worker/fetches/vs/VC/Tools/MSVC/14.39.33519/include/xutility:6608
1  xul.dll  std::max_element  /builds/worker/fetches/vs/VC/Tools/MSVC/14.39.33519/include/xutility:6633
1  xul.dll  std::max_element  /builds/worker/fetches/vs/VC/Tools/MSVC/14.39.33519/include/xutility:6639
1  xul.dll  ots::OpenTypeGLYF::Parse  gfx/ots/src/glyf.cc:485
2  xul.dll  ots::Font::ParseTable  gfx/ots/src/ots.cc:993
3  xul.dll    gfx/ots/src/ots.cc:691
4  xul.dll    gfx/ots/src/ots.cc:275
5  xul.dll  RLBoxProcessWOFF2  gfx/ots/RLBoxWOFF2Host.cpp:233

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

• First crash report: 2024-05-04
• Process type: Multiple distinct types
• Is startup crash: No
• Has user comments: No
• Is null crash: No

Comment 1

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

The Bugbug bot thinks this bug should belong to the 'Core::Graphics' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

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

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

• Top 5 GPU process crashes on release

For more information, please visit BugBot documentation.

Comment 3

[Andrew McCreight [:mccr8]]

Splitting the crashes with this signature for the last two weeks by proto signature, they all have ots::OpenTypeGLYF::Parse in the stack.

Comment 4

[Andrew McCreight [:mccr8]]

In the last week, there have been around 100 of these crashes, but from only 6 different installation times. Half are on 125, and half are on 127. It does look like glyf.cc, the top non-std frame in the crash, changed in Firefox 127, in bug 1870240, so maybe the 127 crashes are a regression from that? Kind of hard to say when the number of installations is so low.

There are a ton of what look like Portuguese websites in the URLs: https://www.idealista.pt/ https://www.ipma.pt/pt/index.html etc though maybe that's just due to the specific person who seems to be crashing a lot. Also a couple of German URLs.

Comment 5

[Andrew McCreight [:mccr8]]

100% of the crashes are on Windows 10, and they all (100%) have the exact same graphics adapter, "Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Integrated Graphics Controller (0x22b1)".

Comment 6

[Jonathan Kew [:jfkthame]]

Strange. We're apparently crashing with an access violation in the call to std::max_element(resulting_offsets.begin(), resulting_offsets.end()) here, which suggests that there's something wrong with the begin() or end() iterators that we're passing to max_element.

But resulting_offsets is just a std::vector<uint32_t> that was allocated (and sized) here, and all we've done with it is to fill in values with simple resulting_offsets[i] = ... assignments. The vector is a local var that's still in scope, so its begin() and end() ought to be perfectly safe to use.

Oh, wait.... what if the range is empty? Then max_element would return the .end() iterator, but that wouldn't be safe to deref... nope, can't be that, because the vector has num_glyphs + 1 elements, so it isn't zero-length even in the degenerate case of a font with no glyphs.

No idea what's happening here....

Comment 7

[Andrew McCreight [:mccr8]]

It also looks like 100% of the crashes are on a specific version of the graphics driver, 20.19.15.5063.

Comment 8

[Gabriele Svelto [:gsvelto]]

All the crashes are from the same type of CPU: family 6 model 76 stepping 4. This is a from Intel's infamous Atom line. We've already ran into CPU bugs in the past with these processors and I'm 99,99% certain that this is another one of them.

Comment 9

[Jonathan Kew [:jfkthame]]

All crashes being on the exact same graphics driver version makes me wonder if it has bug that results in corrupting the (stack-allocated) std::vector<> here?

If it's the result of either a driver bug or a CPU bug (or a combination!), it's hard to see what we can do about this.

Comment 10

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

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

For more information, please visit BugBot documentation.

Comment 11

[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.