Startup Crash in [@ js::frontend::GeneralParser<T>::primaryExpr]
Categories
(Core :: JavaScript Engine, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr78 | --- | wontfix |
firefox87 | --- | unaffected |
firefox88 | --- | wontfix |
firefox89 | --- | wontfix |
firefox90 | --- | wontfix |
People
(Reporter: aryx, Unassigned)
References
Details
(Keywords: crash)
Crash Data
39 crashes for 10 installations of Firefox 88.0 so far. The signature didn't get reported for 86.* and 87.* but existed before with <60 crashes per release cycle.
Crash report: https://crash-stats.mozilla.org/report/index/e8b200cb-bc20-4465-ab3d-851e10210420
Reason: EXCEPTION_ACCESS_VIOLATION_READ
Top 10 frames of crashing thread:
0 xul.dll js::frontend::GeneralParser<js::frontend::FullParseHandler, mozilla::Utf8Unit>::primaryExpr js/src/frontend/Parser.cpp:11627
1 xul.dll js::frontend::GeneralParser<js::frontend::FullParseHandler, mozilla::Utf8Unit>::memberExpr js/src/frontend/Parser.cpp:10052
2 xul.dll js::frontend::GeneralParser<js::frontend::FullParseHandler, mozilla::Utf8Unit>::unaryExpr js/src/frontend/Parser.cpp:9831
3 xul.dll js::frontend::GeneralParser<js::frontend::FullParseHandler, mozilla::Utf8Unit>::assignExpr js/src/frontend/Parser.cpp:9358
4 xul.dll js::frontend::GeneralParser<js::frontend::FullParseHandler, mozilla::Utf8Unit>::memberExpr js/src/frontend/Parser.cpp:10120
5 xul.dll js::frontend::GeneralParser<js::frontend::FullParseHandler, mozilla::Utf8Unit>::unaryExpr js/src/frontend/Parser.cpp:9831
6 xul.dll js::frontend::GeneralParser<js::frontend::FullParseHandler, mozilla::Utf8Unit>::assignExpr js/src/frontend/Parser.cpp:9358
7 xul.dll js::frontend::GeneralParser<js::frontend::FullParseHandler, mozilla::Utf8Unit>::statementListItem js/src/frontend/Parser.cpp:8814
8 xul.dll js::frontend::GeneralParser<js::frontend::FullParseHandler, mozilla::Utf8Unit>::functionFormalParametersAndBody js/src/frontend/Parser.cpp:3504
9 xul.dll js::frontend::Parser<js::frontend::FullParseHandler, mozilla::Utf8Unit>::standaloneLazyFunction js/src/frontend/Parser.cpp:3326
Reporter | ||
Updated•3 years ago
|
Comment 1•3 years ago
|
||
Similar to Bug 1707979, we're seeing crashes near calling pos().begin
, and all recent crashes are at 0x38.
Comment 2•3 years ago
|
||
Crash happens here when Developer Tools are open, and Javascript has changed since the Developer Tools were opened. Either closing Developer Tools or re-loading page uncached (SHIFT-Reload) avoids the problem.
Comment 3•3 years ago
|
||
That is an extremely helpful data point.
Is this something you see every time, or just when the JS is of a certain level of complexity?
Comment 4•3 years ago
|
||
This happend a couple of times for me. Can't comment on the JS complexity. It rather seems to be caused by Developer Tools sometimes showing an outdated, cached version of a script. When you are in this situation, the issue can be triggered also the other way round: restore tab without Developer Tools, then open Developer Tools, then the tab crashes immediately again.
Comment 5•3 years ago
|
||
Thanks so much. Sometime this week I will try to experiment and see if I can come up with a reliable STR.
Comment 6•3 years ago
|
||
One of my crashdumps: https://crash-stats.mozilla.org/report/index/1ba31bbf-372e-4061-ac1f-5cff30210516
Comment 7•3 years ago
|
||
One more Q: do you notice this when there's a specific dev-tools tab open? If it's the Debugger tab, do you have sources or outline view open?
I'm trying to come up with a minimal Steps-to-Reproduce; so if you've got something reliable, I'd love some help narrowing this down.
(What I've tried so far: Simple HTML page with a <script>
tag that I'm manipulating the source and then refreshing a bit)
Comment 8•3 years ago
|
||
When the tab crashes when I open dev-tools, I have no chance to switch the tool, so I can't tell if that would make a difference.
Comment 9•3 years ago
|
||
So looking at a crash report in WinDBG, I see a crash in JSFunction::asyncKind(), which would appear to be a crash reading immutableFlags
off of a nullptr BaseScript
.
0:000> ??@@c++(this->u.scripted.s.script_)
class js::BaseScript * 0x00000000`00000020
+0x000 header_ : mozilla::Atomic<unsigned long long,mozilla::Relaxed,void>
+0x008 warmUpData_ : js::ScriptWarmUpData
+0x010 functionOrGlobal_ : js::GCPtr<JSObject *>
+0x018 sourceObject_ : js::GCPtr<js::ScriptSourceObject *>
+0x020 extent_ : js::SourceExtent
+0x038 immutableFlags_ : js::ImmutableScriptFlags
+0x03c mutableFlags_ : js::MutableScriptFlags
+0x040 data_ : ????
+0x048 sharedData_ : RefPtr<js::SharedImmutableScriptData>
Comment 10•3 years ago
|
||
Michael: How often do you see this? Is it a reliable crash? If so, could you try Firefox nightly? There's a change in there that may actually affect this (fixing it).
Thanks for the link to the crash report: I confirmed it has the same symptoms as others I've been looking at on this bug.
Updated•3 years ago
|
Comment 13•3 years ago
|
||
Thanks for letting me know. Your input has been very valuable nevertheless.
We've got a whole family of similar bugs, so this has been duplicated to one bug, so we track that vs. five smaller ones.
Updated•3 years ago
|
Description
•