1848152 - Crash in [@ mozilla::Span<T>::operator[]] with Stencil

Status: NEW

(Core :: JavaScript Engine, defect, P3)

Description

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

~120 crash reports for Firefox 116.0.x so far (where we accept 10% of the crash reports) vs ~520 for 115.1.0esr (where 100% of submissions get accepted). >40% in the first minute after startup, 75% with 64-bit.

Crash report: https://crash-stats.mozilla.org/report/index/cf028109-caa8-4b8b-adcc-db0a10230810

MOZ_CRASH Reason: MOZ_RELEASE_ASSERT(idx < storage_.size())

Top 10 frames of crashing thread:

0  xul.dll  AnnotateMozCrashReason  mfbt/Assertions.h:43
0  xul.dll  mozilla::Span<JS::GCCellPtr, 18446744073709551615>::operator[] const  mfbt/Span.h:734
0  xul.dll  js::frontend::EmitScriptThingsVector  js/src/frontend/BytecodeSection.cpp:72
0  xul.dll  js::PrivateScriptData::InitFromStencil  js/src/vm/JSScript.cpp:2293
0  xul.dll  JSScript::fullyInitFromStencil  js/src/vm/JSScript.cpp:2417
0  xul.dll  JSScript::fromStencil  js/src/vm/JSScript.cpp:2511
1  xul.dll  InstantiateScriptStencils  js/src/frontend/Stencil.cpp:2085
1  xul.dll  js::frontend::CompilationStencil::instantiateStencilAfterPreparation  js/src/frontend/Stencil.cpp:2481
1  xul.dll  js::frontend::CompilationStencil::instantiateStencils  js/src/frontend/Stencil.cpp:2414
2  xul.dll  js::frontend::InstantiateStencils  js/src/frontend/BytecodeCompiler.cpp:440

Comment 1

[Andrew McCreight [:mccr8]]

This signature is not good. It should get added to the prefix list.

These crashes look like script/stencil things and not the GC.

Comment 2

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

The bug is marked as tracked for firefox116 (release), tracked for firefox117 (beta) and tracked for firefox118 (nightly). We have limited time to fix this, the soft freeze is in 13 days. However, the bug still isn't assigned.

:sdetar, could you please find an assignee for this tracked bug? If you disagree with the tracking decision, please talk with the release managers.

For more information, please visit BugBot documentation.

Comment 3

[Steven DeTar [:sdetar]]

:arai, could you take a look at this bug?

Comment 4

[Tooru Fujisawa [:arai]]

bug 1848369 will add yet another check for data corruption

Comment 5

[Steven DeTar [:sdetar]]

We are adding a checksum in bug 1848369 which may take care of this. I will give this S3/P3 for now.

Comment 6

[Tooru Fujisawa [:arai]]

bug 1848369 patch is applied to central, beta, and esr115.
so far nightly and beta see no crash in recent builds.

Comment 7

[Andrew McCreight [:mccr8]]

Keep in mind that the signature has changed. For instance, the original crash would apparently now be [@ js::frontend::EmitScriptThingsVector ].

Comment 8

[Tooru Fujisawa [:arai]]

just to make sure, can you tell me how EmitScriptThingsVector is considered the changed signature?

to my understanding, EmitScriptThingsVector is another pre-existing issue.

Comment 9

[Andrew McCreight [:mccr8]]

I looked at the crash in comment 0 and it says "Signature generation has changed since this was processed. New signature would be: [@ js::frontend::EmitScriptThingsVector ]". Feel free to remove the signature if you think it isn't applicable for this bug.

Comment 10

[Andrew McCreight [:mccr8]]

Also, the signature changed because in bug 1848162 aryx added mozilla::Span<T> to the skip list for signature generation.

Comment 11

[Tooru Fujisawa [:arai]]

oh, indeed. I misunderstood the meaning of "change". (I thought it's about a change somehow caused by the bug 1848369 patch)
thank you for pointing that out.

I'll track the EmitScriptThingsVector crashes.

Comment 12

[Andrew McCreight [:mccr8]]

Sorry, I could have been more explicit about the cause of the signature change in my initial comment.

Comment 13

[Ryan VanderMeulen [:RyanVM]]

Looks like we've got some EmitScriptThingsVector crash reports coming in from 117.0 and 115.2esr. Maybe we want to track those in a new bug, though.

Comment 14

[Ryan VanderMeulen [:RyanVM]]

As noted in the previous comment, bug 1848369 significantly reduced the crash volume here, but didn't fully eliminate it. I don't think we need to actively track this anymore given the new volume, however.

Comment 15

[Tooru Fujisawa [:arai]]

let's keep using this bug to track the crash itself, but given the crash volume is reduced to the amount before the increase, which is long standing crash around the disk cache corruption, we don't need to track this for the next release.