1852893 - Assertion failure: cx_->hadResourceExhaustion(), at jit/WarpOracle.cpp:200

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect, P2)

Description

[lukas.bernhard]

Steps to reproduce:

On git commit 1cae9ca7cc7d17cfc92088dfc68e5ff391128caa the js-shell asserts when invoked as obj-x86_64-pc-linux-gnu/dist/bin/js --baseline-warmup-threshold=10 --ion-warmup-threshold=100 --fuzzing-safe --fast-warmup --gc-zeal=21,26 crash.js with the attached sample.
I suspect the root cause to be different from bug 1852398 because cherry-picking D188008 doesn't fix this issue. The assert is a bit flaky but rr record --chaos seems to increase ones chances to observe the assert. If needed, I can also upload a pernosco recording.

function main() {
    function f1() {
        const o4 = { 
            get d() {
                return 256n;
            },  
            [undefined]: 256n,
        };  
    }   
    f1();
    for (let v13 = 0; v13 < 100; v13++) {
        (-500000000n).constructor;
    }   
}

for (let v13 = 0; v13 < 100; v13++) {
    main();
}

Comment 1

[Iain Ireland [:iain]]

This is a variant of bug 1851911. The patch for bug 1851911 marks a jitscript as having purged stubs if we remove a stub from its own ICScript. However, this failed to fix the case where we purge a stub from an inlined script.

I think there are actually two versions of this: monomorphic inlining, and trial inlining. The fuzz testcase looks like it hits the trial inlining version, but my first attempt at writing a reduced testcase ran into the monomorphic version instead.

This testcase (lightly modified from bug 1851911) triggers the monomorphic version:

(c);
  }
}

with ({}) {}

function triggerIonCompile() {
  for (var i = 0; i < 10; i++) {
    bar(3);
  }
}

triggerIonCompile();

// Fill up shape list

And this testcase triggers the trial-inlining version:

// |jit-test| --fast-warmup; --no-threads; --blinterp-eager

function foo(o) {
  return foo_inner(o);
}

function foo_inner(o) {
  return o.x;
}
with ({}) {}

for (var i = 0; i < 13; i++) {
  foo({x:1, ["y" + (i % 5)]: 2});
}

for (var i = 0; i < 17; i++) {
  foo({x: 1, ["y" + (i % 8)]: 2});
}

eval("for (var i = 0; i < 10; i++) foo({y: 1, x:2})")

gc();

for (var i = 0; i < 50; i++) {
  foo({x: 1, ["y" + (i % 3)]: 2});
}

The fix for the trial-inlining version is to call notePurgedStubs in JitScript::traceWeak if something is purged anywhere in the inlining root, not just in the ICScript. I think the fix for the monomorphic version is to check whether something we're inlining monomorphically has purged stubs while we're creating the running script hash in WarpOracle.

Comment 2

[Iain Ireland [:iain]]

Attachment: Bug 1852893: Note purged stubs in inlining root r=jandem

Comment 3

[Iain Ireland [:iain]]

Attachment: Bug 1852893: Note purged stubs when monomorphically inlining purged stubs r=jandem

Depends on D188660

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/0eb9057e8b57
Note purged stubs in inlining root r=jandem
https://hg.mozilla.org/integration/autoland/rev/9989293c779f
Note purged stubs when monomorphically inlining purged stubs r=jandem

Comment 5

[Iulian Moraru]

https://hg.mozilla.org/mozilla-central/rev/0eb9057e8b57
https://hg.mozilla.org/mozilla-central/rev/9989293c779f