1835043 - Startup Crash in [@ js::frontend::CompilationAtomCache::getExistingStringAt]

Status: NEW

(Core :: JavaScript Engine, defect, P3)

Description

[Wayne Mery (:wsmwk)]

114.0b4 Startup Crash report: https://crash-stats.mozilla.org/report/index/bf6f0504-1f71-4553-a54e-4cd1e0230525

MOZ_CRASH Reason: MOZ_RELEASE_ASSERT(atoms_.length() >= index)

Top 10 frames of crashing thread:

0  xul.dll  js::frontend::CompilationAtomCache::getExistingStringAt const  js/src/frontend/Stencil.cpp:4591
0  xul.dll  js::frontend::CompilationAtomCache::getExistingStringAt const  js/src/frontend/Stencil.cpp:4599
0  xul.dll  js::frontend::CompilationAtomCache::getExistingAtomAt const  js/src/frontend/Stencil.cpp:4620
1  xul.dll  js::frontend::EmitScriptThingsVector  js/src/frontend/BytecodeSection.cpp:70
2  xul.dll  js::PrivateScriptData::InitFromStencil  js/src/vm/JSScript.cpp:2292
3  xul.dll  JSScript::fullyInitFromStencil  js/src/vm/JSScript.cpp:2416
4  xul.dll  JSScript::fromStencil  js/src/vm/JSScript.cpp:2504
5  xul.dll  InstantiateScriptStencils  js/src/frontend/Stencil.cpp:2085
5  xul.dll  js::frontend::CompilationStencil::instantiateStencilAfterPreparation  js/src/frontend/Stencil.cpp:2481
6  xul.dll  js::frontend::CompilationStencil::instantiateStencils  js/src/frontend/Stencil.cpp:2414

Comment 1

[Magnus Melin [:mkmelin]]

(Don't know about this one.)

Comment 2

[Wayne Mery (:wsmwk)]

M_kato any ideas?

Comment 3

[Makoto Kato [:m_kato] (PTO until 5/6)]

bp-961a38be-68c8-455c-927e-c61310230621 is Firefox 116.0a1. Although this crash is in new JS cache, I don't know why. So we should move to SpiderMonkey team.

Comment 4

[Nicolas B. Pierron [:nbp]]

Looking at the stack trace does not yield anything useful from my point of view.

What sounds the most likely is that one of the Atom's length gets corrupted, and we are crashing while looking it up inside the big strings where all atoms are aggregated as one string.

The various stack traces are all pointing at the instantiate phase of Stencils, but there is no way to link back to what generated the Stencils. Also, given the various context from which the stencil is instantiated would suggest that these are not only cached content, but also freshly parsed content.

Comment 6

[Pascal Chevrel:pascalc]

Setting to S2 as startup crashes are bad for user retention.

Comment 8

[Bryan Thrall [:bthrall]]

The variety of stack traces (such as here, here, and here) imply that the problem isn't with a single code path in instantiating Stencils.

The crash also happens in self-hosted code.

It seems like the problem is likely corruption, as :nbp said in comment 4, or that we are looking at a crash that is a symptom of multiple separate causes.

It is hard to see how we can address this without more information than we have right now.

Comment 9

[Wayne Mery (:wsmwk)]

Firefox crash rate is somewhat reduced from six months ago.
Thunderbird is unchanged, but rare enough to be unimportant.

Unfortunately the stacks cited in comment 8 are gone.

Comment 10

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

The bug is linked to a topcrash signature, which matches the following criterion:

• Top 10 content process crashes on beta

For more information, please visit BugBot documentation.

Comment 11

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

Based on the topcrash criteria, the crash signature linked to this bug is not a topcrash signature anymore.

For more information, please visit BugBot documentation.