1886679 - Assertion failure: !outerScript->hadUnboxFoldingBailout(), at jit/BaselineBailouts.cpp:2080

Status: RESOLVED DUPLICATE of bug 1872525

(Core :: JavaScript Engine: JIT, defect)

Description

[lukas.bernhard]

Steps to reproduce:

On git commit f63ca2952da98e0817bdae0ddf1314281a497106 the attached sample asserts in the js-shell when invoked as obj-x86_64-pc-linux-gnu/dist/bin/js --fast-warmup --fuzzing-safe crash.js
The assert is flakey but rr record --chaos should do the trick. Otherwise, I can provide a pernos.co record.
Guessing not s-s due to the interrupt calls.

let v2;
try {
const t0 = 268435440;
v2 = t0();
} catch (e) {}
const t6 = 268435440 >= v2 ? 268435440 : v2;
const v5 = delete t6?.[20581];
const v7 = [-1,-65535,19594287,536870912,65536];
for (let i9 = 1000; i9-- > 0;) {
}
const v16 = String();
for (let v17 = 0; v17 < 10; v17++) {
    v17 < 10;
    let v20 = 0;
    function f21() {
        if (v20++ < 10) {
            interruptIf(true);
        }
        v16[4];
        v5["h"] = v20;
        v7[2352];
        delete String[0];
        return true;
    }
    setInterruptCallback(f21);
    f21();
}

    #0 0x5e57cba79de8 in js::jit::FinishBailoutToBaseline(js::jit::BaselineBailoutInfo*) js/src/jit/BaselineBailouts.cpp:2080:7
    #1 0x7ef54233f1b9  ([anon:js-executable-memory]+0x1b9)
    #2 0x7ef54233fd80  ([anon:js-executable-memory]+0xd80)
    #3 0x5e57cc0d4256 in EnterJit(JSContext*, js::RunState&, unsigned char*) js/src/jit/Jit.cpp:115:5
    #4 0x5e57cc0d4256 in js::jit::MaybeEnterJit(JSContext*, js::RunState&) js/src/jit/Jit.cpp:261:10
    #5 0x5e57cabc76b5 in js::RunScript(JSContext*, js::RunState&) js/src/vm/Interpreter.cpp:441:32
    #6 0x5e57cabc842e in js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason) js/src/vm/Interpreter.cpp:605:13
    #7 0x5e57cabca43d in js::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, js::AnyInvokeArgs const&, JS::MutableHandle<JS::Value>, js::CallReason) js/src/vm/Interpreter.cpp:672:8
    #8 0x5e57cadd2d7f in JS_CallFunctionValue(JSContext*, JS::Handle<JSObject*>, JS::Handle<JS::Value>, JS::HandleValueArray const&, JS::MutableHandle<JS::Value>) js/src/vm/CallAndConstruct.cpp:55:10
    #9 0x5e57caabda42 in ShellInterruptCallback(JSContext*) js/src/shell/js.cpp:1032:16
    #10 0x5e57cb137226 in HandleInterrupt(JSContext*, bool) js/src/vm/Runtime.cpp:415:10
    #11 0x5e57cb137226 in JSContext::handleInterrupt() js/src/vm/Runtime.cpp:488:12
    #12 0x5e57cba78691 in js::jit::FinishBailoutToBaseline(js::jit::BaselineBailoutInfo*) js/src/jit/BaselineBailouts.cpp:1971:10
    #13 0x7ef54233f1b9  ([anon:js-executable-memory]+0x1b9)
    #14 0x7ef54233fd80  ([anon:js-executable-memory]+0xd80)
    #15 0x5e57cc0d4256 in EnterJit(JSContext*, js::RunState&, unsigned char*) js/src/jit/Jit.cpp:115:5
    #16 0x5e57cc0d4256 in js::jit::MaybeEnterJit(JSContext*, js::RunState&) js/src/jit/Jit.cpp:261:10
    #17 0x5e57cabc76b5 in js::RunScript(JSContext*, js::RunState&) js/src/vm/Interpreter.cpp:441:32
    #18 0x5e57cabc842e in js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason) js/src/vm/Interpreter.cpp:605:13
    #19 0x5e57cabca43d in js::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, js::AnyInvokeArgs const&, JS::MutableHandle<JS::Value>, js::CallReason) js/src/vm/Interpreter.cpp:672:8
    #20 0x5e57cadd2d7f in JS_CallFunctionValue(JSContext*, JS::Handle<JSObject*>, JS::Handle<JS::Value>, JS::HandleValueArray const&, JS::MutableHandle<JS::Value>) js/src/vm/CallAndConstruct.cpp:55:10
    #21 0x5e57caabda42 in ShellInterruptCallback(JSContext*) js/src/shell/js.cpp:1032:16
    #22 0x5e57cb137226 in HandleInterrupt(JSContext*, bool) js/src/vm/Runtime.cpp:415:10
    #23 0x5e57cb137226 in JSContext::handleInterrupt() js/src/vm/Runtime.cpp:488:12
    #24 0x5e57cba78691 in js::jit::FinishBailoutToBaseline(js::jit::BaselineBailoutInfo*) js/src/jit/BaselineBailouts.cpp:1971:10
    #25 0x7ef54233f1b9  ([anon:js-executable-memory]+0x1b9)
    #26 0x7ef54233fd80  ([anon:js-executable-memory]+0xd80)

Comment 1

[Steven DeTar [:sdetar]]

Iain, could you take a quick look at this bug and help us to triage it. Since it seems to have to do with Bailouts, I thought you might be a good person to take a first look.

Comment 2

[Iain Ireland [:iain]]

This is very similar to bug 1872525: an assertion in FinishBailoutToBaseline is violated because we interrupt ourselves in the middle of bailing out to run arbitrary code that also bails out. The fix for that bug removed the only call to handleInterrupt in FinishBailoutToBaseline, so this crash stack is similarly no longer possible.

I verified that I can reproduce the crash on the version immediately before the fix, and that the crash no longer occurs post-fix.