The following testcase crashes on mozilla-central revision 20201219-3262affdccf6 (--enable-debug build, run with --fuzzing-safe --differential-testing --ion-offthread-compile=off --fast-warmup):

function testMathyFunction(f, inputs) {
  var results = [];
  for (var j = 0; j < inputs.length; ++j) 
    for (var k = 0; k < inputs.length; ++k) 
      results.push(f(inputs[j], inputs[k]));
}
mathy0 = (function(x, y) {
  return (Math.clz32((x <= x) >>> y) >> (~(0x080000000 >>> 0))) % Math.acos(~(2 ** 53)) >>> 0
});
testMathyFunction(mathy0, [1, 42, 0 / 0, 1 / 0, -Number.MIN_SAFE_INTEGER, -(2 ** 53), (2 ** 53), 1.7976931348623157e308]);

Backtrace:

received signal SIGSEGV, Segmentation fault.
0x00005555575f618e in js::jit::FinishBailoutToBaseline(js::jit::BaselineBailoutInfo*) ()
#0  0x00005555575f618e in js::jit::FinishBailoutToBaseline(js::jit::BaselineBailoutInfo*) ()
#1  0x000020cefbc521e7 in ?? ()
[...]
#15 0x0000000000000000 in ?? ()
rax	0x555555838409	93824995263497
rbx	0x7ffff6024000	140737320730624
rcx	0x555557fca8d8	93825036757208
rdx	0x0	0
rsi	0x7ffff7105770	140737338431344
rdi	0x7ffff7104540	140737338426688
rbp	0x7fffffffb630	140737488336432
rsp	0x7fffffffb4d0	140737488336080
r8	0x7ffff7105770	140737338431344
r9	0x7ffff7f998c0	140737353717952
r10	0x58	88
r11	0x7ffff6dac7a0	140737334921120
r12	0x6	6
r13	0x0	0
r14	0xffffb801	4294948865
r15	0x1e	30
rip	0x5555575f618e <js::jit::FinishBailoutToBaseline(js::jit::BaselineBailoutInfo*)+5422>
=> 0x5555575f618e <_ZN2js3jit23FinishBailoutToBaselineEPNS0_19BaselineBailoutInfoE+5422>:	movl   $0x7ea,0x0
   0x5555575f6199 <_ZN2js3jit23FinishBailoutToBaselineEPNS0_19BaselineBailoutInfoE+5433>:	callq  0x555556a8e79a <abort>

Please consider fixing this quickly because jsfunfuzz keeps hitting this quite frequently. It was previously covered by the other bug with the same assert.

Iain, could you investigate this bug, this could be caused by changes in the bailout code you have been making.

Similarly to the previous bug, this is just a performance issue, not security-sensitive.

I'm not sure whether anybody is around to review a full fix, so for now to unblock fuzzing I'll put up a patch to disable the assertion.

Once I have an actual fix, maybe we can fuzz that patch before landing to verify that I've plugged all the holes. I have another patch stack almost ready to go with additional assertions that we may be able to fuzz at the same time.

Bugmon Analysis:
Verified bug as reproducible on mozilla-central 20201221155804-2c9db4cd3d89.
The bug appears to have been introduced in the following build range:

Start: ce4363056f26b132a08b7640e09d1a73b2fbf72e (20201208212755)
End: 63a3451d9bcc637f6b269aa4ea2b852655906b01 (20201208213733)
Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=ce4363056f26b132a08b7640e09d1a73b2fbf72e&tochange=63a3451d9bcc637f6b269aa4ea2b852655906b01

https://hg.mozilla.org/mozilla-central/rev/249c57822ca3

The next patch will add a method to RangeAnalysis with a TruncateKind argument. Nested enums can't be forward-declared, so instead of undoing anba's work in bug 1669181 (part 35), I'm un-nesting the enum.

There were two bugs here:

1. We weren't checking hadEagerTruncationBailout before eagerly truncating phis.
2. MDiv::operandTruncateKind and MMod::operandTruncateKind can return TruncateAfterBailouts even if ComputeTruncateKind returns a less restrictive kind. We therefore have to check the operands too.

Depends on D100750

I removed this assertion temporarily to unblock fuzzing over the holidays. Now that we've fixed the bugs, we can put it back.

Depends on D100751

https://hg.mozilla.org/mozilla-central/rev/7944733c5201
https://hg.mozilla.org/mozilla-central/rev/114f361d728d
https://hg.mozilla.org/mozilla-central/rev/fdbcd1cd62e2

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

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