1877709 - Crash [@ js::jit::DoToBoolFallback] or Assertion failure: v.isObject(), at builtin/Boolean.cpp:175

Status: RESOLVED DUPLICATE of bug 1877357

(Core :: JavaScript Engine: JIT, defect)

Description

[Christian Holler (:decoder)]

The following testcase crashes on mozilla-central revision 20240131-ad50a175a7c5 (opt build, run with --fuzzing-safe --wasm-compiler=baseline+optimizing --ion-warmup-threshold=0 --fast-warmup --no-threads):

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]));
}
mathy1=(function(stdlib,foreign,heap){
  ff = foreign.ff;
  Float32ArrayView = new stdlib.Float32Array(heap);
  Uint32ArrayView = new stdlib.Uint32Array(heap);
  function f(d0) {
    var i2=0;
    var i4;
    i2=Float32ArrayView[2];
    i4=i2;
    ff(2,0) ? f : 6;
    Uint32ArrayView[!!d0] + [...[eval]]
    return i4 ? 1 : 0;
  }
return f
})(this,{ ff:(Function('')) },new SharedArrayBuffer(40));
testMathyFunction(mathy1,[Math.N,Number.M,(2),Number.M])

Backtrace:

received signal SIGSEGV, Segmentation fault.
0x0000555556e24485 in js::jit::DoToBoolFallback(JSContext*, js::jit::BaselineFrame*, js::jit::ICFallbackStub*, JS::Handle<JS::Value>, JS::MutableHandle<JS::Value>) ()
#0  0x0000555556e24485 in js::jit::DoToBoolFallback(JSContext*, js::jit::BaselineFrame*, js::jit::ICFallbackStub*, JS::Handle<JS::Value>, JS::MutableHandle<JS::Value>) ()
#1  0x000024274aaad140 in ?? ()
#2  0x00007fffffffc000 in ?? ()
#3  0xfff9800000000000 in ?? ()
#4  0x000000000000007f in ?? ()
#5  0x00007fffffffc000 in ?? ()
#6  0x000024274aab4752 in ?? ()
#7  0x0000000000000001 in ?? ()
#8  0x00007fffffffbfb8 in ?? ()
#9  0x00007ffff3ea97b0 in ?? ()
#10 0xfffa800000000009 in ?? ()
#11 0xfffa800000000009 in ?? ()
#12 0xfffa800000000009 in ?? ()
#13 0x000034b3fa360100 in ?? ()
#14 0x00007ffff3d2e160 in ?? ()
#15 0x00007ffff3ea95b0 in ?? ()
#16 0x000013c170a006d0 in ?? ()
#17 0x00007ffff3ea9468 in ?? ()
#18 0x0000000000000000 in ?? ()
rax	0x4800000000009	1266637395197961
rbx	0x7fffffffbf68	140737488338792
rcx	0xfffa000000000000	-1688849860263936
rdx	0xfffe000000000000	-562949953421312
rsi	0x0	0
rdi	0x7fffffffbdd0	140737488338384
rbp	0x7fffffffbf50	140737488338768
rsp	0x7fffffffbd40	140737488338240
r8	0x7fffffffbea8	140737488338600
r9	0x0	0
r10	0x9	9
r11	0xfff9800000000000	-1829587348619264
r12	0x7ffff3e20100	140737285062912
r13	0x7ffff3ea9468	140737285624936
r14	0xfffa800000000000	-1548112371908608
r15	0x7ffff3ea97b0	140737285625776
rip	0x555556e24485 <js::jit::DoToBoolFallback(JSContext*, js::jit::BaselineFrame*, js::jit::ICFallbackStub*, JS::Handle<JS::Value>, JS::MutableHandle<JS::Value>)+1445>
=> 0x555556e24485 <_ZN2js3jit16DoToBoolFallbackEP9JSContextPNS0_13BaselineFrameEPNS0_14ICFallbackStubEN2JS6HandleINS7_5ValueEEENS7_13MutableHandleIS9_EE+1445>:	mov    (%rax),%rdi
   0x555556e24488 <_ZN2js3jit16DoToBoolFallbackEP9JSContextPNS0_13BaselineFrameEPNS0_14ICFallbackStubEN2JS6HandleINS7_5ValueEEENS7_13MutableHandleIS9_EE+1448>:	testb  $0x30,0x8(%rdi)

Marking s-s due to invalid read in JIT code.

Comment 1

[Christian Holler (:decoder)]

Attachment: Detailed Crash Information

Comment 2

[Christian Holler (:decoder)]

Attachment: Testcase

Comment 3

[Bugmon [:jkratzer for issues]]

Verified bug as reproducible on mozilla-central 20240131095100-ad50a175a7c5.
The bug appears to have been introduced in the following build range:

Start: 34f197ce93a24d93523617eba67ecee2e990c37c (20240125152629)
End: dd2a416c0c76b4cc9f6161d6be89aa7356e4eae5 (20240125205047)
Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=34f197ce93a24d93523617eba67ecee2e990c37c&tochange=dd2a416c0c76b4cc9f6161d6be89aa7356e4eae5

Comment 4

[Matthew Gaudet (he/him) [:mgaudet]]

Possibly coming from Bug 1842773?

Comment 5

[André Bargull [:anba]]

(In reply to Matthew Gaudet (he/him) [:mgaudet] from comment #4)

Possibly coming from Bug 1842773?

No, it's from https://hg.mozilla.org/integration/autoland/rev/7ad5c59c746bbde34ba4a1bb08ba6aa1c65dbacd (bug 1874456).

Comment 6

[Matthew Gaudet (he/him) [:mgaudet]]

Thank you for checking!

Comment 7

[Nicolas B. Pierron [:nbp] {away}]

Testing with and without the patch made for Bug 1877357, highlight that this other patch fixes this issue.
I will investigate, to verify that this is the same root cause.

Comment 8

[Nicolas B. Pierron [:nbp] {away}]

I confirm, this is a duplicate of Bug 1877357.

The problem being that the function is being compiled with an OSR entry as well as the normal entry.
The Phi added to merge between the 2 entries is typed as a double, and thus coerces both inputs to be doubles.

However, as the coercion instruction is added in the block in which the instruction is last seen instead of being in one of the predecessors, the life time observed by EliminateDeadResumePointOperands appears shortended, and unused, thus hidding the need for the capturing the value for longer. Thus, letting EliminateDeadResumePointOperand replace the apparently unused operands by the magic value which causes the crash after a bailout.

I will add this test case as part of the other patch.

Comment 9

[Bugmon [:jkratzer for issues]]

No valid actions for resolution (DUPLICATE).
Removing bugmon keyword as no further action possible. Please review the bug and re-add the keyword for further analysis.