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

Status: RESOLVED FIXED

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

Description

[Christian Holler (:decoder)]

The following testcase crashes on mozilla-central revision 20210407-b740f950e497 (debug build, run with --fuzzing-safe --differential-testing --no-threads --baseline-eager --ion-warmup-threshold=0):

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) {}
}
mathy4=(function() {
  new Float64Array(1003900229)()
});
testMathyFunction(mathy4, [,,,,1])

Backtrace:

received signal SIGSEGV, Segmentation fault.
#0  0x000055555791a9a3 in js::jit::WarpOracle::createSnapshot() ()
#1  0x00005555578b6806 in js::jit::CreateWarpSnapshot(JSContext*, js::jit::MIRGenerator*, JS::Handle<JSScript*>) ()
#2  0x000055555789623f in js::jit::Compile(JSContext*, JS::Handle<JSScript*>, js::jit::BaselineFrame*, unsigned char*) ()
#3  0x0000555557896fc7 in IonCompileScriptForBaseline(JSContext*, js::jit::BaselineFrame*, unsigned char*) ()
#4  0x00001028d59bd715 in ?? ()
#5  0x0000000000000000 in ?? ()
rax	0x55555572ad04	93824994159876
rbx	0x7ffff6026000	140737320738816
rcx	0x555557ffc488	93825036960904
rdx	0x0	0
rsi	0x7ffff7105770	140737338431344
rdi	0x7ffff7104540	140737338426688
rbp	0x7fffffffb1f0	140737488335344
rsp	0x7fffffffb150	140737488335184
r8	0x7ffff7105770	140737338431344
r9	0x7ffff7f99840	140737353717824
r10	0x0	0
r11	0x0	0
r12	0x7ffff5e1da50	140737318607440
r13	0x7fffffffb210	140737488335376
r14	0x7ffff604e3c8	140737320903624
r15	0xbb6764bd	3144115389
rip	0x55555791a9a3 <js::jit::WarpOracle::createSnapshot()+1635>
=> 0x55555791a9a3 <_ZN2js3jit10WarpOracle14createSnapshotEv+1635>:	movl   $0xbe,0x0
   0x55555791a9ae <_ZN2js3jit10WarpOracle14createSnapshotEv+1646>:	callq  0x555556a7fa0f <abort>

Comment 1

[Christian Holler (:decoder)]

Attachment: Testcase

Comment 2

[Bugmon [:jkratzer for issues]]

Bugmon Analysis:
Verified bug as reproducible on mozilla-central 20210408095111-83a21ab93aff.
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]]

The bug here is that the length check in tryAttachTypedArrayConstructor only verifies that the byte length doesn't overflow, but the length check in makeTypedArrayWithTemplate compares against TypedArrayObject::maxByteLength(), which is smaller. If the length is too long but fits in 32 bits, then we attach and transpile a stub, but it never succeeds. In Warp, we realize that the NewTypedArray result is unused and remove it, then bail out when we hit the unreachable code that follows. The fix is to make the length check more precise in GetTemplateObjectForNative.

Comment 4

[Iain Ireland [:iain]]

Attachment: Bug 1703817: Make length check more precise for tryAttachTypedArrayConstructor r=jandem

The length check in tryAttachTypedArrayConstructor only verifies that the byte length doesn't overflow 32 bits, but the length check in makeTypedArrayWithTemplate compares against TypedArrayObject::maxByteLength(), which is smaller. Aligning the two checks eliminates a bailout loop.

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/dc742b480e45
Make length check more precise for tryAttachTypedArrayConstructor r=jandem

Comment 6

[Andreea Pavel [:apavel]]

https://hg.mozilla.org/mozilla-central/rev/dc742b480e45

Comment 7

[Bugmon [:jkratzer for issues]]

Bugmon Analysis:
Bug marked as FIXED but still reproduces on mozilla-central 20210412213434-b0d9f96ea571.

Comment 8

[Iain Ireland [:iain]]

The original testcase doesn't fail for the same reason as before; now it's just very slow because Lars enabled --large-buffers by default (and eventually I think it OOMs). Jan pointed this problem out during review, and the testcase I added avoids the problem by requesting an even larger array buffer.

Comment 9

[Bugmon [:jkratzer for issues]]

Bugmon Analysis:
Bug marked as FIXED but still reproduces on mozilla-central 20210412213434-b0d9f96ea571.

Comment 10

[Iain Ireland [:iain]]

jkratzer: The patch I landed fixed the attached testcase, which involves trying to allocate an over-sized TypedArray. In the meantime, a separate patch landed that increased the maximum size of array buffers. Now, the allocation succeeds and the attached testcase runs out of memory instead, which is not interesting.

I'm confident that the fix is correct. What is the best way to tell Bugmon to stop reopening this bug?

Comment 11

[Jason Kratzer [:jkratzer]]

Ian, apologies for the spam. Bugmon has no way of differentiating between the crashes. Removing the bugmon keyword is the easiest way to prevent any further analysis.

Comment 12

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

:iain, since this bug contains a bisection range, could you fill (if possible) the regressed_by field?
For more information, please visit auto_nag documentation.