1687228 - Crash in [@ js::BaseScript::enclosingScope]

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect, P1)

Description

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

4 crashes on 2 machines on the weekend (Windows, macOS).

Could this be from bug 1683276?

Crash report: https://crash-stats.mozilla.org/report/index/18ece91a-9dcc-4a69-afd7-cf1690210117

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

Top 10 frames of crashing thread:

0 xul.dll js::BaseScript::enclosingScope const js/src/vm/JSScript.cpp:716
1 xul.dll js::frontend::CompilationStencilSet::instantiateStencilsAfterPreparation js/src/frontend/Stencil.cpp:754
2 xul.dll js::frontend::InstantiateStencils js/src/frontend/BytecodeCompiler.cpp:341
3 xul.dll js::ParseTask::instantiateStencils js/src/vm/HelperThreads.cpp:705
4 xul.dll js::ScriptDecodeTask::parse js/src/vm/HelperThreads.cpp:807
5 xul.dll js::ParseTask::runHelperThreadTask js/src/vm/HelperThreads.cpp:607
6 xul.dll static js::HelperThread::ThreadMain js/src/vm/HelperThreads.cpp:2335
7 xul.dll static js::detail::ThreadTrampoline<void  js/src/threading/Thread.h:206
8 ucrtbase.dll thread_start<unsigned int , 1> 
9 kernel32.dll BaseThreadInitThunk 

Comment 1

[Tooru Fujisawa [:arai]]

most likely from bug 1667804.
the code path is enabled by the patch.
the patch can be disabled by flipping javascript.options.off_thread_parse_global to true, so setting to S3.

If we're delazifying a script, it shouldn't reach gcthings()[js::GCThingIndex::outermostScopeIndex()], given it's for non-lazy script.

https://searchfox.org/mozilla-central/rev/dac45cc7020dfddbcc937827810dd11550c07dc3/js/src/vm/JSScript.cpp#713

js::Scope* js::BaseScript::enclosingScope() const {
  MOZ_ASSERT(!warmUpData_.isEnclosingScript(),
             "Enclosing scope is not computed yet");

  if (warmUpData_.isEnclosingScope()) {
    return warmUpData_.toEnclosingScope();
  }

  MOZ_ASSERT(data_, "Script doesn't seem to be compiled");

  return gcthings()[js::GCThingIndex::outermostScopeIndex()]
      .as<Scope>()
      .enclosing();
}

if the script is lazy, and ready for delazification, it should hit warmUpData_.isEnclosingScope().
will look into how the condition gets missed.

Comment 2

[Tooru Fujisawa [:arai]]

Given the script have just been instantiated, the possibilities I can think of are:

• a) the enclosing script's delazification is somehow not stored into XDR buffer
• b) the delazificationIndices map or functionKey calculation is broken, and it's delazifying wrong script

Comment 3

[Ted Campbell [:tcampbell]]

It is possible the XDR data had a bit flip or something. A simple hardening for that would be to add a check for isReadyForDelazification instead the CompilationStencilSet instantiation loop. This would prevent crashes and give us a chance to maybe catch an assert on CI.

if (!lazy->isReadyForDelazification()) {
  MOZ_ASSERT("Delazification target is not ready. Bad XDR?");
  continue;
}

Comment 4

[Tooru Fujisawa [:arai]]

Attachment: Bug 1687228 - Skip delazification data without the enclosing script delazified. r?tcampbell!

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/cc62780e619f
Skip delazification data without the enclosing script delazified. r=tcampbell

Comment 6

[Alexandru Michis [:malexandru]]

https://hg.mozilla.org/mozilla-central/rev/cc62780e619f