1502047 - Crash in js::irregexp::ChoiceNode::Emit

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect, P3)

Description

[[:philipp]]

This bug was filed from the Socorro interface and is
report bp-7a22eaf9-1677-42a4-a372-609ec0181025.
=============================================================

Top 9 frames of crashing thread:

0  @0x7ffda8e15500 
1 xul.dll js::irregexp::ChoiceNode::Emit js/src/irregexp/RegExpEngine.cpp:4473
2 xul.dll js::irregexp::RegExpCompiler::Assemble js/src/irregexp/RegExpEngine.cpp:1689
3 xul.dll js::irregexp::CompilePattern js/src/irregexp/RegExpEngine.cpp:1863
4 xul.dll js::RegExpShared::compile js/src/vm/RegExpObject.cpp:1025
5 xul.dll js::RegExpShared::execute js/src/vm/RegExpObject.cpp:1080
6 xul.dll static js::RegExpRunStatus ExecuteRegExp js/src/builtin/RegExp.cpp:966
7 xul.dll js::RegExpMatcher js/src/builtin/RegExp.cpp:1021
8  @0x2269be0d1fc 

=============================================================

this content crash signature is spiking up in the firefox 63.0 release from 64bit installations on windows. the signature is currently the #20 top content crash making up 0.4% of all content crashes on release.

the spike seems to be tied to the amd ryzen cpu "family 23 model 1 stepping 1". during the 63 beta cycle the crash with this cpu only showed up in betas 3,4,13 and the final rc - so it may be a build specific crash.

https://crash-stats.mozilla.com/signature/?_sort=-date&cpu_info=%7Efamily%2023%20model%201%20stepping%201&signature=js%3A%3Airregexp%3A%3AChoiceNode%3A%3AEmit&date=%3E%3D2018-08-01

Comment 1

[[:philipp]]

some more similar signatures are correlated to this particular cpu.

Comment 2

[Randell Jesup [:jesup] (needinfo me)]

Adding dmajor since he's been involved in a lot of CPU-stepping-specific and compiler/PGO opt-specific crashes.  (adding glandium too)

Comment 3

[Ted Campbell [:tcampbell]]

Weird Ryzen crashes have often come back as bad ram / overclocking when I've investigated in past. Crashes on arithmetic and bit-flip-like crashes. The people I've emailed later confirmed they had bad ram.

One bizarre thing is a lot of the fault addresses end in 0x5500. Looking at the disassembly of a could of crashes, I cannot reconcile the register state. The code and stack and setup for a virtual call to NativeRegExpMacroAssembler::Bind, but registers are zero so something must have happened in between.

The fault address is typically in unmapped address space before xul.dll.

I'm not sure what next steps are.

Comment 4

[[:philipp]]

the issue seems to have been a build-specific one as the crash pattern is no longer present in the 63.0.1 dot-release...

Comment 5

[Randell Jesup [:jesup] (needinfo me)]

I see 4 crashes in 63.0.1.

Also, I see lots in 64.0b6 - many with EXEC of the exact same address (and not from the same install/machine): 
https://crash-stats.mozilla.com/signature/?signature=js%3A%3Airregexp%3A%3AChoiceNode%3A%3AEmit&date=%3E%3D2018-10-21T23%3A21%3A32.000Z&date=%3C2018-11-04T18%3A21%3A32.000Z&_columns=date&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=reason&_columns=address&_columns=install_time&_sort=-date&page=1

Comment 6

[Randell Jesup [:jesup] (needinfo me)]

Should have been hidden!  EXEC of wildptrs

Comment 7

[Daniel Veditz [:dveditz] back January 5, 2026]

Limiting crash reports to "js::irregexp::" and EXCEPTION_ACCESS_VIOLATION_EXEC only 24 of 420 are something other than "family 23 model 1 stepping 1", and the specific signatures of those 24 don't look like the rest. Yes, I see 64.0b6 crashes that look like this, but not 64.0b5 or earlier. I do see one _EXEC in 63.0.1, but crashing at a different function and not in the most common js::irregexp::ChoiceNode::Emit signature.

I don't see anything inconsistent with it being a Ryzen build-specific weirdness wrt "the spike" of crashes. There are a few other similar-looking crashes mixed in that might be security bugs but it doesn't seem fruitful to mash them into one investigation.

Comment 8

[Ted Campbell [:tcampbell]]

The spikes are gone, but there are low levels of crashes still. Ideally we'd finish project to update irregexp for feature reasons but that seems far off.

The bulk of crashes seem to be on Ryzen so not much worth doing.

Comment 10

[David Lawrence [:dkl]]

Removing employee no longer with company from CC list of private bugs.

Comment 11

[Ted Campbell [:tcampbell]]

Crash rate is almost zero, and we've migrated the regexp engine since then.

Comment 12

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

Since the bug is closed, the stalled keyword is now meaningless.
For more information, please visit auto_nag documentation.