crash when opening website (js::irregexp::RegExpParser<T>::ParseDisjunction)
Categories
(Core :: JavaScript Engine, defect, P1)
Tracking
()
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!
Comment 1•5 years ago
|
||
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
Comment 2•5 years ago
|
||
We can indeed see an increase of this signature over the last few days on Nightly, thanks Sören for reporting it!
Comment 3•5 years ago
|
||
Iain, this might be the same issue as bug 1585264.
Comment 4•5 years ago
|
||
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.
Updated•5 years ago
|
Description
•