Closed Bug 1585275 Opened 5 years ago Closed 5 years ago

crash when opening website (js::irregexp::RegExpParser<T>::ParseDisjunction)

Categories

(Core :: JavaScript Engine, defect, P1)

Desktop
All
defect

Tracking

()

RESOLVED DUPLICATE of bug 1585264
Tracking Status
firefox-esr60 --- wontfix
firefox69 --- wontfix
firefox70 --- fix-optional
firefox71 --- fixed

People

(Reporter: soeren.hentzschel, Unassigned)

Details

(Keywords: crash, regression, regressionwindow-wanted)

Crash Data

Unfortunately I don't have reliable STR. But there is a new crash which sometimes occour when opening the administration of my WordPress blog. It always has the same signature:

js::irregexp::RegExpParser<T>::ParseDisjunction

One of my crash reports:
https://crash-stats.mozilla.org/report/index/4bfbdc26-62ba-416f-a277-654460191001

According to the crash stats there are also crashes with the same signature in older Firefox versions but for me it happens since yesterday's Nightly and never before so I will mark this as regression. I already submitted four crash reports in the short time.

But it doesn't always happen so it's hard to reproduce. So far it only happened on my working machine with macOS 10.11, I was not yet able to reproduce on my private machine with macOS 10.15 Beta. But I used my private maschine much less since yesterday so I can't say for sure if this machine is unaffected or not.

Since it only happens for my WordPress administration and not on other websites I can't share a link publicly but you can send me an e-mail if you need a test access.

Let me know if you need more information!

This bug is for crash report bp-4bfbdc26-62ba-416f-a277-654460191001.

Top 10 frames of crashing thread:

0 XUL js::irregexp::RegExpParser<unsigned char>::ParseDisjunction js/src/irregexp/RegExpParser.cpp
1 XUL js::irregexp::ParsePatternSyntax js/src/irregexp/RegExpParser.cpp:2004
2 XUL js::RegExpObject::create js/src/vm/RegExpObject.cpp:269
3 XUL mozilla::Result<mozilla::Ok, JS::TranscodeResult> js::XDRScriptRegExpObject< js/src/vm/RegExpObject.cpp:1411
4 XUL mozilla::Result<mozilla::Ok, JS::TranscodeResult> js::XDRScript< js/src/vm/JSScript.cpp:1180
5 XUL mozilla::Result<mozilla::Ok, JS::TranscodeResult> js::XDRInterpretedFunction< js/src/vm/JSFunction.cpp:627
6 XUL mozilla::Result<mozilla::Ok, JS::TranscodeResult> js::XDRScript< js/src/vm/JSScript.cpp:1180
7 XUL js::XDRState< js/src/vm/Xdr.cpp:311
8 XUL mozilla::dom::ScriptLoader::EvaluateScript js/src/jsapi.cpp:5876
9 XUL mozilla::dom::ScriptLoader::ProcessRequest dom/script/ScriptLoader.cpp:2315

Crash Signature: [@ js::irregexp::RegExpParser<T>::ParseDisjunction]

We can indeed see an increase of this signature over the last few days on Nightly, thanks Sören for reporting it!

Component: Untriaged → JavaScript Engine
OS: macOS → All
Product: Firefox → Core

Iain, this might be the same issue as bug 1585264.

Flags: needinfo?(iireland)
Priority: -- → P1

It looks very similar. The failures went away when we backed out the atom deduplication code, and the stack trace is consistent with things going wrong in XDR. It's a little weird that we're seeing a crash in the regexp code, instead of the atom code, but xdr is delicate enough that I'm not that surprised.

Status: NEW → RESOLVED
Closed: 5 years ago
Flags: needinfo?(iireland)
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.