1745907 - Assertion failure: cx_->hadNondeterministicException(), at js/src/jit/WarpOracle.cpp:189

Status: VERIFIED FIXED

(Core :: JavaScript Engine: JIT, defect, P3)

Description

[Christian Holler (:decoder)]

The following testcase crashes on mozilla-central revision 20211214-51773d1ab7b5 (debug build, run with --fuzzing-safe --no-threads --fast-warmup):

for (let v3 = 0; v3 < 100; v3++) {
    function v4(v5,v6) {}
    function v7(v8,v9) {
        v14 = BigInt(-1.7976931348623157e+308);
        try {
            v15 = BigInt.asUintN(639625512,v14);
        } catch(v17) {}
    }
    v18 = v4.prototype;
    v18.b = v7;
    v19 = new v4();
    v20 = v19.b();
}

Backtrace:

received signal SIGSEGV, Segmentation fault.
#0  0x00005555577dae38 in js::jit::WarpOracle::createSnapshot() ()
#1  0x0000555557aa0e26 in js::jit::CreateWarpSnapshot(JSContext*, js::jit::MIRGenerator*, JS::Handle<JSScript*>) ()
#2  0x0000555557a817fd in js::jit::Compile(JSContext*, JS::Handle<JSScript*>, js::jit::BaselineFrame*, unsigned char*) ()
#3  0x0000555557a823f9 in IonCompileScriptForBaseline(JSContext*, js::jit::BaselineFrame*, unsigned char*) ()
#4  0x0000555557a82bba in js::jit::IonCompileScriptForBaselineOSR(JSContext*, js::jit::BaselineFrame*, unsigned int, unsigned char*, js::jit::IonOsrTempData**) ()
[...]
#8  0x0000000000000000 in ?? ()
rax	0x55555572abf5	93824994159605
rbx	0x0	0
rcx	0x5555581c3f90	93825038827408
rdx	0x0	0
rsi	0x7ffff7105770	140737338431344
rdi	0x7ffff7104540	140737338426688
rbp	0x7fffffffb8e0	140737488337120
rsp	0x7fffffffb840	140737488336960
r8	0x7ffff7105770	140737338431344
r9	0x7ffff7f99840	140737353717824
r10	0x0	0
r11	0x0	0
r12	0x7ffff60194a0	140737320686752
r13	0x7fffffffb900	140737488337152
r14	0x7ffff5a26f78	140737314451320
r15	0xaacbb5db	2865477083
rip	0x5555577dae38 <js::jit::WarpOracle::createSnapshot()+1528>
=> 0x5555577dae38 <_ZN2js3jit10WarpOracle14createSnapshotEv+1528>:	movl   $0xbd,0x0
   0x5555577dae43 <_ZN2js3jit10WarpOracle14createSnapshotEv+1539>:	callq  0x555556b603b3 <abort>

Comment 1

[Christian Holler (:decoder)]

Attachment: Detailed Crash Information

Comment 2

[Christian Holler (:decoder)]

Attachment: Testcase

Comment 3

[Bugmon [:jkratzer for issues]]

Bugmon Analysis
Verified bug as reproducible on mozilla-central 20211214094205-4243f988e94a.
The bug appears to have been introduced in the following build range:

Start: 1add9a1bbfacd4ff1bee961fa8886b8cd0566d23 (20210227094458)
End: 80f5cb43d64e45bad9247216faa6553d836e53fe (20210227004609)
Pushlog: https://hg.mozilla.org/mozilla-unified/pushloghtml?fromchange=1add9a1bbfacd4ff1bee961fa8886b8cd0566d23&tochange=80f5cb43d64e45bad9247216faa6553d836e53fe

Comment 4

[Bugmon [:jkratzer for issues]]

Bugmon Analysis
Verified bug as reproducible on mozilla-central 20211214094205-4243f988e94a.
The bug appears to have been introduced in the following build range:

Start: 1add9a1bbfacd4ff1bee961fa8886b8cd0566d23 (20210227094458)
End: 80f5cb43d64e45bad9247216faa6553d836e53fe (20210227004609)
Pushlog: https://hg.mozilla.org/mozilla-unified/pushloghtml?fromchange=1add9a1bbfacd4ff1bee961fa8886b8cd0566d23&tochange=80f5cb43d64e45bad9247216faa6553d836e53fe

Comment 5

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

That bisect range is showing up on hg.mozilla.org as am empty set. The fromchange and tochange parameters appear to be backwards?

Having said that, if you flip the parameters, the range is definitely weird: I'm not seeing any JS engine changes in that range at all. non-determinism leading to a bad bisect perhaps?

Comment 6

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

I think this one goes to you Iain

Comment 7

[Jason Kratzer [:jkratzer]]

(In reply to Matthew Gaudet (he/him) [:mgaudet] from comment #5)

That bisect range is showing up on hg.mozilla.org as am empty set. The fromchange and tochange parameters appear to be backwards?

Having said that, if you flip the parameters, the range is definitely weird: I'm not seeing any JS engine changes in that range at all. non-determinism leading to a bad bisect perhaps?

This looks like bugmon is failing to report the range properly when one revision is from mozilla-central and the other is from autoland. Setting the repo to mozilla-central reveals:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=1add9a1bbfacd4ff1bee961fa8886b8cd0566d23&tochange=80f5cb43d64e45bad9247216faa6553d836e53fe

Could it possibly be bug 1694600?

Comment 8

[Iain Ireland [:iain]]

It makes sense that the patch in bug 1694600 that improved the precision of bailout loop detection would make this start to fail. The underlying issue predates that bug, though: it's the same basic issue as this comment on bug 1720032.

We attach an IC for the call to BigInt.asUintN. That IC makes a VM call, which throws because the result would have too many digits. As a result, we don't hit the SetGName for v15 =. When we warp-compile this code, we transpile the AsUintN call, and generate an unconditional bail for the SetGName, because it's never been reached. The optimizer sees that we won't use the result of the AsUintN call without bailing, and optimizes it away.

Therefore, instead of trying to allocate an oversized BigInt and throwing, the warp script hits the unconditional bailout for the SetGName. We resume at the beginning of the try block, enter the IC, and throw again. We still don't hit the SetGName, so when we recompile, the CacheIR is the same. We detect a bailout loop and assert.

We have a similar known issue with string concatenation, where Ion optimizes away allocations and doesn't throw, but it can't cause bailout loop issues like we see here because we won't attach an IC unless the string concatenation has already succeeded, so the subsequent code will execute at least once.

I think the reasonable fixes for this are to either skip attaching call ICs for inlinable natives if the call throws an exception, or to decide that (just like OOM and stack overflow) we're not interested in bailout loops that involve hitting implementation-defined limits, and treat allocation overflow as a nondeterministic exception that disables bailout loop checks.

Comment 9

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

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

Comment 11

[Iain Ireland [:iain]]

Attachment: Bug 1745907: Treat oversized string/bigint allocations as nondeterministic r=jandem

The testcase triggers a bailout loop in the bigint case. It's not possible to write an equivalent testcase for string concatenation, because we don't attach a stub unless the concatenation succeeds.

I've also verified that this prints a message for the fuzzer in all the differential testcases I could find.

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/539e8e6bc09d
Treat oversized string/bigint allocations as nondeterministic r=jandem

Comment 13

[Iulian Moraru]

https://hg.mozilla.org/mozilla-central/rev/539e8e6bc09d

Comment 14

[Bugmon [:jkratzer for issues]]

Bugmon Analysis
Verified bug as fixed on rev mozilla-central 20220114045818-344f14b85f84.
Removing bugmon keyword as no further action possible. Please review the bug and re-add the keyword for further analysis.