Closed Bug 1703817 Opened 4 years ago Closed 4 years ago

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

Categories

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

x86_64
Linux
defect

Tracking

()

RESOLVED FIXED
89 Branch
Tracking Status
firefox-esr78 --- wontfix
firefox87 --- wontfix
firefox88 --- wontfix
firefox89 --- fixed

People

(Reporter: decoder, Assigned: iain)

References

(Regression)

Details

(Keywords: assertion, regression, testcase, Whiteboard: [bugmon:update,bisected,confirmed])

Attachments

(2 files)

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>
Attached file Testcase

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

Whiteboard: [bugmon:update,bisect] → [bugmon:update,bisected,confirmed]

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.

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.

Assignee: nobody → iireland
Status: NEW → ASSIGNED
Pushed by iireland@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/dc742b480e45 Make length check more precise for tryAttachTypedArrayConstructor r=jandem
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → 89 Branch

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

Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Severity: -- → S4
Priority: -- → P1

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.

Status: REOPENED → RESOLVED
Closed: 4 years ago4 years ago
Resolution: --- → FIXED

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

Status: RESOLVED → REOPENED
Resolution: FIXED → ---

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?

Flags: needinfo?(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.

Flags: needinfo?(jkratzer)
Keywords: bugmon
Status: REOPENED → RESOLVED
Closed: 4 years ago4 years ago
Resolution: --- → FIXED

: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.

Flags: needinfo?(iireland)
Flags: needinfo?(iireland)
Regressed by: 1673497
Has Regression Range: --- → yes
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: