1966325 - Assertion failure: allocSitesSpace_.isEmpty(), at jit/JitScript.cpp:61

Status: RESOLVED FIXED

(Core :: JavaScript Engine: JIT, defect)

Description

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Attachment: Console.app stack from macOS

abcd1 = 5;
function ff() {
  for (
    let ii = 10;
    ii;
    (() => {
      ii--;
      function fff() {
        fff;
      }
      v = { 1() {}, h(xx) {} };
    })()
  )
    for (let i, jjj = 1; jjj--, jjj; ) {}
  this.oomTest(ff);
}
ff();

Backtraces are from unreduced testcase, which is also just as intermittent.

[13030] Assertion failure: allocSitesSpace_.isEmpty(), at /Users/p4m1/trees/mozilla-central/js/src/jit/JitScript.cpp:61
#01: js::jit::ICScript::~ICScript()[/Users/p4m1/shell-cache/js-dbg-64-fzli-darwin-arm64-bff55607678c/js-dbg-64-fzli-darwin-arm64-bff55607678c +0x16dca1c]
#02: js::jit::ICScript::addInlinedChild(JSContext*, mozilla::UniquePtr<js::jit::ICScript, JS::DeletePolicy<js::jit::ICScript>>, unsigned int)[/Users/p4m1/shell-cache/js-dbg-64-fzli-darwin-arm64-bff55607678c/js-dbg-64-fzli-darwin-arm64-bff55607678c +0x16de8d0]
#03: js::jit::TrialInliner::createInlinedICScript(JSFunction*, js::BytecodeLocation)[/Users/p4m1/shell-cache/js-dbg-64-fzli-darwin-arm64-bff55607678c/js-dbg-64-fzli-darwin-arm64-bff55607678c +0x10cb384]
#04: js::jit::TrialInliner::maybeInlineCall(js::jit::ICEntry&, js::jit::ICFallbackStub*, js::BytecodeLocation)[/Users/p4m1/shell-cache/js-dbg-64-fzli-darwin-arm64-bff55607678c/js-dbg-64-fzli-darwin-arm64-bff55607678c +0x10cba40]
#05: js::jit::TrialInliner::tryInlining()[/Users/p4m1/shell-cache/js-dbg-64-fzli-darwin-arm64-bff55607678c/js-dbg-64-fzli-darwin-arm64-bff55607678c +0x10c70e0]
#06: js::jit::DoTrialInlining(JSContext*, js::jit::BaselineFrame*)[/Users/p4m1/shell-cache/js-dbg-64-fzli-darwin-arm64-bff55607678c/js-dbg-64-fzli-darwin-arm64-bff55607678c +0x10c68bc]
/snip

The intermittence is making it very difficult to bisect. If someone can make this testcase reliable, a bisection window can be produced easily.

Run with --fuzzing-safe --ion-eager --fast-warmup --inlining-entry-threshold=64, compile with AR=ar 'PATH="/Users/USER/trees/depot_tools:/Users/USER/.local/state/fnm_multishells/772_1747172985416/bin:/usr/share/doc/git/contrib/diff-highlight:/Users/USER/.local/bin:/usr/local/bin:/opt/homebrew/bin:/opt/homebrew/sbin:/Users/USER/.deno/bin:/Users/USER/.cargo/bin:/usr/bin:/bin:/usr/sbin:/sbin"' sh ../configure --enable-debug --enable-fuzzing --enable-js-fuzzilli --disable-shared-js --with-ccache --enable-gczeal --enable-rust-simd --disable-tests, tested on m-c rev bff55607678c.

I'm not sure if the testcase reproduces without fuzzilli configs, in any case run this testcase between 500-1000 times, and maybe more, it might be reproducible.

Setting s-s as a start. Jan, this is likely in your ballpark for now.

Comment 1

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Attachment: Console output from macOS

I've attached console output from macOS.

Separately, I got this to assert on Ubuntu Linux 22.04 LTS once, after 1426 runs, so it's probably not macOS-only. Number of runs that are > 1000 may also be needed.

Comment 2

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Oh, I may have a successful bisection in the next few days, I had an assertion failure on Linux after 960 seconds (16 minutes of continuous running the same testcase).

It may help to have running processes in the background taking up loads of CPU / memory, e.g. a fuzzing run.

Comment 3

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Attachment: Ubuntu stack

    #0 0x64e2b5d33f2d in MOZ_CrashSequence(void*, long) /home/ubu32gx500/shell-cache/js-dbg-64-fzli-linux-x86_64-bff55607678c/objdir-js/dist/include/mozilla/Assertions.h:248:3
    #1 0x64e2b5d33f2d in js::jit::ICScript::~ICScript() /home/ubu32gx500/trees/mozilla-central/js/src/jit/JitScript.cpp:61:3
    #2 0x64e2b5d361da in void js_delete<js::jit::ICScript>(js::jit::ICScript const*) /home/ubu32gx500/shell-cache/js-dbg-64-fzli-linux-x86_64-bff55607678c/objdir-js/dist/include/js/Utility.h:581:9
    #3 0x64e2b5d361da in JS::DeletePolicy<js::jit::ICScript>::operator()(js::jit::ICScript const*) /home/ubu32gx500/shell-cache/js-dbg-64-fzli-linux-x86_64-bff55607678c/objdir-js/dist/include/js/Utility.h:654:35
    #4 0x64e2b5d361da in mozilla::UniquePtr<js::jit::ICScript, JS::DeletePolicy<js::jit::ICScript>>::reset(js::jit::ICScript*) /home/ubu32gx500/shell-cache/js-dbg-64-fzli-linux-x86_64-bff55607678c/objdir-js/dist/include/mozilla/UniquePtr.h:302:7
    #5 0x64e2b5d361da in mozilla::UniquePtr<js::jit::ICScript, JS::DeletePolicy<js::jit::ICScript>>::~UniquePtr() /home/ubu32gx500/shell-cache/js-dbg-64-fzli-linux-x86_64-bff55607678c/objdir-js/dist/include/mozilla/UniquePtr.h:250:18
    #6 0x64e2b5d361da in js::jit::ICScript::addInlinedChild(JSContext*, mozilla::UniquePtr<js::jit::ICScript, JS::DeletePolicy<js::jit::ICScript>>, unsigned int) /home/ubu32gx500/trees/mozilla-central/js/src/jit/JitScript.cpp:261:7
    #7 0x64e2b572d980 in js::jit::TrialInliner::createInlinedICScript(JSFunction*, js::BytecodeLocation) /home/ubu32gx500/trees/mozilla-central/js/src/jit/TrialInlining.cpp:723:19
    #8 0x64e2b572e16c in js::jit::TrialInliner::maybeInlineCall(js::jit::ICEntry&, js::jit::ICFallbackStub*, js::BytecodeLocation) /home/ubu32gx500/trees/mozilla-central/js/src/jit/TrialInlining.cpp:775:27
    #9 0x64e2b57297d3 in js::jit::TrialInliner::tryInlining() /home/ubu32gx500/trees/mozilla-central/js/src/jit/TrialInlining.cpp:907:14
    #10 0x64e2b5729077 in js::jit::DoTrialInlining(JSContext*, js::jit::BaselineFrame*) /home/ubu32gx500/trees/mozilla-central/js/src/jit/TrialInlining.cpp:103:18
    #11 0x5a5b8dafbb5  ([anon:js-executable-memory]+0x5a5b8dafbb5)

Comment 4

[Jan de Mooij [:jandem]]

I wonder if this code needs to move after the addInlinedChild call after it.

Comment 5

[Jon Coppeard (:jonco)]

(In reply to Jan de Mooij [:jandem] from comment #4)
Thanks Jan that looks like it's the problem.

I can reproduce this locally after ~20000 interations. GNU parallel helps a lot.

Comment 6

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

The first bad revision is:
changeset:   https://hg.mozilla.org/mozilla-central/rev/709f58f3b5fd
user:        Jon Coppeard
date:        Sat May 10 08:54:11 2025 +0000
summary:     Bug 1965061 - Part 1: Add an allocation site for environment objects r=jandem

Oh well...

Comment 7

[Jon Coppeard (:jonco)]

Attachment: Bug 1966325 - Don't allocate alloc site until we known creating an inlined IC script has succeeded r?jandem

Comment 8

[Jon Coppeard (:jonco)]

Attachment: Bug 1966325 - Add test case r?jandem

Comment 9

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

Set release status flags based on info from the regressing bug 1965061

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/37794094f89b
Don't allocate alloc site until we known creating an inlined IC script has succeeded r=jandem
https://hg.mozilla.org/integration/autoland/rev/8f31be999b7e
Add test case r=jandem

Comment 11

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

https://hg.mozilla.org/mozilla-central/rev/37794094f89b
https://hg.mozilla.org/mozilla-central/rev/8f31be999b7e