1699056 - Assertion failure: cx_->hadNondeterministicException(), at jit/WarpOracle.cpp:188

Status: VERIFIED FIXED

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

Description

[Christian Holler (:decoder)]

The following testcase crashes on mozilla-central revision 20210315-29ed711969d6 (debug build, run with --fuzzing-safe --no-threads --fast-warmup):

function testMathyFunction(f, inputs) {
  for (var j = 0; j < inputs.length; ++j) 
    for (var k = 0; k < inputs.length; ++k) 
      try {
        f(inputs[j], inputs[k])
      } catch (e) {}
}
s0 = '';
s2 = '';
var x;
this.toString = (function(j) {
  s0 += 'x';
  s2 += s0;
});
mathy5 = (function(x, y) {
  y >>> 0;
  Math.min(x,x);
  y >>> 0;
  Math.fround(y);
  Math.atan(y);
  Math.fround(y);
});
testMathyFunction(mathy5, [
  x, false, x, x, (0/0), (0/0), (0/0), x, this, this, x, false, x
  , this, x, false, x, this, x, x, this, x, this, false, this, x, (0/0), false
  , (0/0), this, (0/0), this, false, (0/0), x, x, x, x, x, x, x, x, x, x, x, x
  , x, false, (0/0), (0/0), false, (0/0), (0/0), (0/0), this, false, this, this
  , x, this, (0/0), false, this, (0/0), x, (0/0), this, this, this, this, this
  , this, (0/0), false, this, false, x, x, this, false, x, this, this, this
  , this, this, this, this, this, this, this, this, this, this, this, this, x
  , x, false, false, this, false, false, this, (0/0), x, this, (0/0), this
  , false, false, x, false, false, (0/0), x, false, x, (0/0), (0/0), false
  , (0/0), x, this, x, x, this, false, false, x, false, false, false, false
  , (0/0), x, this, (0/0), this, false, this, x, (0/0), (0/0), false, x, x
  , (0/0), x, (0/0), this, false, (0/0), this, x, (0/0), false, false, x
]);

Backtrace:

received signal SIGSEGV, Segmentation fault.
0x000055555790df6b in js::jit::WarpOracle::createSnapshot() ()
#0  0x000055555790df6b in js::jit::WarpOracle::createSnapshot() ()
#1  0x00005555578aaa96 in js::jit::CreateWarpSnapshot(JSContext*, js::jit::MIRGenerator*, JS::Handle<JSScript*>) ()
#2  0x000055555788aa0b in js::jit::Compile(JSContext*, JS::Handle<JSScript*>, js::jit::BaselineFrame*, unsigned char*) ()
#3  0x000055555788b797 in IonCompileScriptForBaseline(JSContext*, js::jit::BaselineFrame*, unsigned char*) ()
#4  0x00003d4063f12715 in ?? ()
[...]
#12 0x0000000000000000 in ?? ()
rax	0x55555572e11c	93824994173212
rbx	0x7ffff6026000	140737320738816
rcx	0x555557ff1088	93825036914824
rdx	0x0	0
rsi	0x7ffff7105770	140737338431344
rdi	0x7ffff7104540	140737338426688
rbp	0x7fffffffac20	140737488333856
rsp	0x7fffffffab80	140737488333696
r8	0x7ffff7105770	140737338431344
r9	0x7ffff7f99840	140737353717824
r10	0x58	88
r11	0x7ffff6dac7a0	140737334921120
r12	0x7ffff6087cf0	140737321139440
r13	0x7fffffffac40	140737488333888
r14	0x7ffff5e465d8	140737318774232
r15	0xc8256e0a	3357896202
rip	0x55555790df6b <js::jit::WarpOracle::createSnapshot()+1627>
=> 0x55555790df6b <_ZN2js3jit10WarpOracle14createSnapshotEv+1627>:	movl   $0xbc,0x0
   0x55555790df76 <_ZN2js3jit10WarpOracle14createSnapshotEv+1638>:	callq  0x555556a7e364 <abort>

Comment 1

[Christian Holler (:decoder)]

Attachment: Testcase

Comment 2

[Bugmon [:jkratzer for issues]]

Bugmon Analysis:
Verified bug as reproducible on mozilla-central 20210317095331-9ad67cd4d216.
The bug appears to have been introduced in the following build range:

Start: f4af0087a1b49c221f54143a10b7bebca35db49c (20210111195436)
End: febd0fad07331284c49334bab4d9c653f2c80275 (20210111195806)
Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=f4af0087a1b49c221f54143a10b7bebca35db49c&tochange=febd0fad07331284c49334bab4d9c653f2c80275

Comment 3

[Iain Ireland [:iain]]

Here's a cut-down testcase.

var a = '';
var b = '';

function foo() {
    a += 'x';
    b = b + a;
}

with ({}) {}
for (var i = 0; i < 50000; i++) {
    try { foo() } catch {}
}

We build up an unreasonably long string in b. Eventually, a.length + b.length > JSString::MAX_LENGTH, and ConcatStrings starts throwing. Somewhere along the line, all these string allocations have triggered a GC, which caused us to purge IC stubs. However, the stub for concatenation in b + a is allocated in the fallback space and can't be purged. Because the b + a stub always throws, when we bail out and run in baseline, the SetGName IC for b = b + a is never reached, so we don't attach a new stub to replace the purged one. When we recompile in Warp, we generate an MBail for the SetGName. Because of this, the MConcat for b + a doesn't have any uses, and since it can be recovered on bailout, we remove it.

But then we don't actually try concatenating in the Warp script, so Warp doesn't throw. Instead it hits the bailout and resumes in baseline, which does throw. When we recompile, nothing has changed, so we assert.

I'm still thinking about the best fix. I'm not convinced we care about this case, so maybe we should just turn off the assertion if we've purged stubs from an ICScript.

Comment 4

[Intermittent Failures Robot]

1 failures in 3967 pushes (0.0 failures/push) were associated with this bug in the last 7 days.

Repository breakdown:

• mozilla-central: 1

Platform and build breakdown:

• android-hw-p2-8-0-android-aarch64-qr: 1
  • debug: 1

For more details, see:
https://treeherder.mozilla.org/intermittent-failures/bugdetails?bug=1699056&startday=2021-03-22&endday=2021-03-28&tree=all

Comment 5

[Iain Ireland [:iain]]

Attachment: Bug 1699056: Disable bailout assertion after purging stubs r=jandem

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/8021fa44c7ea
Disable bailout assertion after purging stubs r=jandem

Comment 7

[Natalia Csoregi [:nataliaCs]]

https://hg.mozilla.org/mozilla-central/rev/8021fa44c7ea

Comment 8

[Bugmon [:jkratzer for issues]]

Bugmon Analysis:
Verified bug as fixed on rev mozilla-central 20210401031248-5c46535ee223.
Removing bugmon keyword as no further action possible.
Please review the bug and re-add the keyword for further analysis.