Assertion failure: cx_->hadNondeterministicException(), at jit/WarpOracle.cpp:190
Categories
(Core :: JavaScript Engine: JIT, defect, P1)
Tracking
()
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>
Reporter | ||
Comment 1•4 years ago
|
||
Comment 2•4 years ago
|
||
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
Assignee | ||
Comment 3•4 years ago
|
||
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
.
Assignee | ||
Comment 4•4 years ago
|
||
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.
Updated•4 years ago
|
Comment 6•4 years ago
|
||
bugherder |
Updated•4 years ago
|
Comment 7•4 years ago
|
||
Bugmon Analysis:
Bug marked as FIXED but still reproduces on mozilla-central 20210412213434-b0d9f96ea571.
Updated•4 years ago
|
Assignee | ||
Comment 8•4 years ago
|
||
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.
Updated•4 years ago
|
Comment 9•4 years ago
|
||
Bugmon Analysis:
Bug marked as FIXED but still reproduces on mozilla-central 20210412213434-b0d9f96ea571.
Assignee | ||
Comment 10•4 years ago
|
||
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•4 years ago
|
||
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.
Updated•4 years ago
|
Comment 12•4 years ago
|
||
: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.
Updated•4 years ago
|
Description
•