1706991 - Crash in [@ JSScript::fullyInitFromStencil]

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect, P3)

Description

[Ryan VanderMeulen [:RyanVM]]

Lots of wildptr-looking reads in these reports. Looks like a low-volume crash that's been around for awhile now

Crash report: https://crash-stats.mozilla.org/report/index/11ed3241-75fb-4071-b580-8f1370210422

Reason: EXCEPTION_ACCESS_VIOLATION_READ

Top 10 frames of crashing thread:

0 xul.dll static JSScript::fullyInitFromStencil js/src/vm/JSScript.cpp:3794
1 xul.dll static JSScript::fromStencil js/src/vm/JSScript.cpp:3849
2 xul.dll static js::frontend::CompilationStencil::instantiateStencilAfterPreparation js/src/frontend/Stencil.cpp:1341
3 xul.dll js::frontend::InstantiateStencils js/src/frontend/BytecodeCompiler.cpp:386
4 xul.dll js::ParseTask::instantiateStencils js/src/vm/HelperThreads.cpp:722
5 xul.dll js::ScriptDecodeTask::parse js/src/vm/HelperThreads.cpp:836
6 xul.dll js::ParseTask::runHelperThreadTask js/src/vm/HelperThreads.cpp:619
7 xul.dll static js::HelperThread::ThreadMain js/src/vm/HelperThreads.cpp:2364
8 xul.dll static js::detail::ThreadTrampoline<void  js/src/threading/Thread.h:205
9 ucrtbase.dll thread_start<unsigned int > 

Comment 1

[Ryan VanderMeulen [:RyanVM]]

https://crash-stats.mozilla.org/report/index/1543659f-4ff1-4d0c-98be-18bcd0210422 shows MOZ_RELEASE_ASSERT(idx < storage_.size()) in case that's relevant.

Comment 2

[Ryan VanderMeulen [:RyanVM]]

Matthew, Stencil lives in your realm I believe?

Comment 3

[Matthew Gaudet (he/him) [:mgaudet]]

I'm in the neighbourhood, but I'm going to redirect to Ted and Arai who are doing the heavy lifting around this of late.

Peeking at a few more crash reports, most seem to be off-thread decode, though this one is invoked from the AsyncScriptCompiler.

I was fighting a similar looking on Android during my work on converting the ScriptPreloader to stencil (not yet landed!); in that case it was a lifetime issue: we were producing a Stencil that was living longer than the XDR buffer it was borrowing from.

Comment 4

[Daniel Veditz [:dveditz]]

This signature has at least two different release assert reasons, and a bunch of crashes that are not asserts. Looks like multiple bugs, at least 3?

The release asserts seem to start in 86.0.1 (and 78.9). There were a handful of a different crash before then.

The assert reasons look dangerous -- would likely be sec-high if the asserts didn't protect us.

Comment 5

[Ted Campbell [:tcampbell]]

Marking as stalled. This seems in the same vein as Bug 1423616. I think we are down in the weeds of disk/memory corruption and we have continued to add more consistency checks that are pushing crashes around.

I've filed Bug 1728369 to look at adding telemetry to better understand if the relative proportion of various integrity checks catching issues. Understanding which sieve of check is first catching the bulk of errors might help narrow down if there are real issues, or if this is just another example of the first code to touch some memory being the one to be blamed for crashes.

Comment 6

[Daniel Veditz [:dveditz]]

The crashes after ESR-102 don't look terribly scary: lowering severity

Comment 7

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

Since the bug is closed, the stalled keyword is now meaningless.
For more information, please visit auto_nag documentation.