Crash report: https://crash-stats.mozilla.org/report/index/2dbd1de3-50f3-44c5-8838-2fc080230628

Reason: EXCEPTION_ACCESS_VIOLATION_WRITE

Top 10 frames of crashing thread:

0  xul.dll  enumEitherTrie  intl/icu/source/common/utrie2.cpp:490
1  xul.dll  CompileLazyFunctionToStencilMaybeInstantiate<mozilla::Utf8Unit>  js/src/frontend/BytecodeCompiler.cpp:1302
2  xul.dll  _tailMerge_hid.dll  
3  xul.dll  _tailMerge_hid.dll  
4  xul.dll  _tailMerge_hid.dll  
5  xul.dll  utrie2_enum_72  intl/icu/source/common/utrie2.cpp:623
6  xul.dll  uchar_addPropertyStarts_72  intl/icu/source/common/uchar.cpp:669
7  xul.dll    intl/icu/source/common/characterproperties.cpp:116
8  xul.dll  icu_72::umtx_initOnce<UPropertySource>  intl/icu/source/common/umutex.h:202
9  xul.dll    intl/icu/source/common/characterproperties.cpp:206

This bug is a very low volume, and probably not worth a lot of attention.

The frame 1-4 sounds like non-sense and should probably be ignored.
The stack suggest that ICU is called from the RegExp parser.

10 xul.dll icu_72::UnicodeSet::applyIntPropertyValue(UProperty, int, UErrorCode&) intl/icu/source/common/uniset_props.cpp:782
11 xul.dll v8::internal::(anonymous namespace)::(anonymous namespace)::LookupPropertyValueName(UProperty, char const*, bool, v8::internal::ZoneList<v8::internal::CharacterRange>, v8::internal::ZoneMap<v8::base::Vector<const unsigned int>, v8::internal::RegExpTree, v8::internal::CharacterClassStringLess>, JS::RegExpFlags, v8::internal::Zone) js/src/irregexp/imported/regexp-parser.cc:1891

Any idea what might possibily be going wrong between the RegExp and ICU.
Also, this bug is most likely cross-browser given that both have the same RegExp engine and the same Internationalization library.
Maybe there are some hints in v8?

Yeah, this backtrace looks unreliable. How did the SM frontend end up in the middle of an ICU stack? The only part of this that I trust is that we crashed inside enumEitherTrie. Looking at the minidump, we're storing to a nullptr. If there were a null dereference bug in ICU, I would expect to hit it more often than this. Out of the 22 crashes in enumEitherTrie in the last six months, only two were null pointers. Bucketing by install time, 18 of the 22 crashes were from installs that crashed more than once, and the details of the crash look much more consistent within installs than between installs, which I take as evidence of binary corruption. One install crashed 7 times with an illegal instruction. That's definitely a bad binary.

This looks like background noise, not a real bug.