1661728 - [warp] Assertion failure: targetScript->jitScript() == icScript->jitScript(), at /builds/worker/checkouts/gecko/js/src/jit/WarpOracle.cpp:974

Status: RESOLVED FIXED

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

Description

[Christian Holler (:decoder)]

The following testcase crashes on mozilla-central revision 20200827-109f3a4de567 (debug build, run with --fuzzing-safe --cpu-count=2 --ion-offthread-compile=off --warp --disable-oom-functions):

assertEq = function(a,b) {}
egc = 4;
gczeal(14,egc);
function wasmEvalText(str, imports) {
  let binary = wasmTextToBinary(str);
    m = new WebAssembly.Module(binary);
  return new WebAssembly.Instance(m, imports);
}
const PAGESIZE = 65536;
function mem_fill(min, max, shared, backup, write=backup*2) {
    let ins = wasmEvalText(`
      (memory (export "mem") ${min} ${max} ${shared})
      (func (param $offs i32) (param $val i32) (param $len i32)
        (memory.fill (local.get $offs) (local.get $val) (local.get $len))
      )
   `);
  let offs = min*PAGESIZE - backup;
  let v79 = new Uint8Array(ins.exports.mem.buffer);
  for (let i32=0; i32 < backup; i32++)
    assertEq(v79[offs+i32], 0);
  for (let i32=0; i32 < offs; i32++)
    assertEq(v79[i32], 0);
}
mem_fill(1, 1, "", 257);
mem_fill(1, 1, "", 257, 0xFFFFFFFF);

Backtrace:

received signal SIGSEGV, Segmentation fault.
#0  WarpScriptOracle::maybeInlineCallIC (this=0x7fffffffb250, snapshots=..., loc=..., stub=0x7ffff60fe070, fallbackStub=0x7ffff5a2a750, stubDataCopy=0x7ffff5668cf0 "\300\315\371\313s\a") at js/src/jit/WarpOracle.cpp:974
#1  0x000055555788617b in WarpScriptOracle::maybeInlineIC (this=0x7fffffffb250, snapshots=..., loc=...) at js/src/jit/WarpOracle.cpp:943
#2  0x0000555557882b7b in WarpScriptOracle::createScriptSnapshot (this=0x7fffffffb250) at js/src/jit/WarpOracle.cpp:305
#3  0x0000555557882439 in js::jit::WarpOracle::createSnapshot (this=0x7fffffffb2f0) at js/src/jit/WarpOracle.cpp:142
#4  0x0000555557aee145 in js::jit::CreateWarpSnapshot (cx=0x7ffff6027000, mirGen=0x7ffff5668208, script=...) at js/src/jit/Ion.cpp:1603
#5  0x0000555557aed9f5 in js::jit::IonCompile (cx=0x7ffff6027000, script=..., baselineFrame=0x7fffffffb780, baselineFrameSize=152, osrPc=0x7ffff5675161 "\230\033", recompile=false, optimizationLevel=js::jit::OptimizationLevel::Normal) at js/src/jit/Ion.cpp:1696
#6  0x0000555557adc1f3 in js::jit::Compile (cx=0x7ffff6027000, script=..., osrFrame=0x7fffffffb780, osrFrameSize=152, osrPc=0x7ffff5675161 "\230\033", forceRecompile=false) at js/src/jit/Ion.cpp:1966
#7  0x0000555557adc9e4 in BaselineCanEnterAtBranch (cx=0x7ffff6027000, script=..., osrFrame=0x7fffffffb780, osrFrameSize=152, pc=0x7ffff5675161 "\230\033") at js/src/jit/Ion.cpp:2164
#8  IonCompileScriptForBaseline (cx=0x7ffff6027000, frame=0x7fffffffb780, frameSize=<optimized out>, pc=0x7ffff5675161 "\230\033") at js/src/jit/Ion.cpp:2216
#9  0x0000555557add01d in js::jit::IonCompileScriptForBaselineOSR (cx=0x7ffff6027000, frame=0x7fffffffb780, frameSize=152, pc=0x7ffff5675161 "\230\033", infoPtr=0x7fffffffb700) at js/src/jit/Ion.cpp:2345
#10 0x00000f7b7413cd97 in ?? ()
#11 0xfff8800000000000 in ?? ()
#12 0x00007fffffffb700 in ?? ()
#13 0x0000000000000000 in ?? ()
rax	0x555555841b5e	93824995302238
rbx	0xaaaaaaaaaaaaaaaa	-6148914691236517206
rcx	0x555558520aa8	93825042352808
rdx	0x0	0
rsi	0x7ffff7105770	140737338431344
rdi	0x7ffff7104540	140737338426688
rbp	0x7fffffffb030	140737488334896
rsp	0x7fffffffaed0	140737488334544
r8	0x7ffff7105770	140737338431344
r9	0x7ffff7f9de00	140737353735680
r10	0x58	88
r11	0x7ffff6dac7a0	140737334921120
r12	0x7ffff567518e	140737310577038
r13	0x7fffffffb250	140737488335440
r14	0x7ffff5a2a750	140737314465616
r15	0x7ffff60fe070	140737321623664
rip	0x5555578874ca <WarpScriptOracle::maybeInlineCallIC(mozilla::LinkedList<js::jit::WarpOpSnapshot>&, js::BytecodeLocation, js::jit::ICStub*, js::jit::ICFallbackStub*, unsigned char*)+2122>
=> 0x5555578874ca <WarpScriptOracle::maybeInlineCallIC(mozilla::LinkedList<js::jit::WarpOpSnapshot>&, js::BytecodeLocation, js::jit::ICStub*, js::jit::ICFallbackStub*, unsigned char*)+2122>:	movl   $0x3ce,0x0
   0x5555578874d5 <WarpScriptOracle::maybeInlineCallIC(mozilla::LinkedList<js::jit::WarpOpSnapshot>&, js::BytecodeLocation, js::jit::ICStub*, js::jit::ICFallbackStub*, unsigned char*)+2133>:	callq  0x555556bd99ae <abort()>

The test here is unfortunately not stable and I wasn't able to find a stable configuration, no matter what kind of GC parameters I chose.

Comment 1

[Christian Holler (:decoder)]

Attachment: Testcase

Comment 2

[Jason Kratzer [:jkratzer]]

Bugmon Analysis:
Unable to reproduce bug using the following builds:
> mozilla-central 20200828153126-56166cae2e26
> mozilla-central 20200827212940-109f3a4de567
Removing bugmon keyword as no further action possible.
Please review the bug and re-add the keyword for further analysis.

Comment 3

[Iain Ireland [:iain]]

This is a good catch. Patch coming shortly.

Comment 4

[Iain Ireland [:iain]]

Attachment: Bug 1661728: Remove ICScript::jitScript_ r=jandem

The bug here occurs when we:
a) Trial-inline A into B, creating an ICScript owned by B with a pointer to A's JitScript.
b) Perform a compacting GC, discarding the JitScript for A, but preserving the JitScript for B (because it is on the stack).
c) Create a new JitScript for A.
d) Warp-compile B, without hitting the B->A trial-inlined call IC.

In this case, the JitScript* stored in the ICScript created in a) is dangling, and does not match the JitScript created in c).

The easy way to fix this is to not store a JitScript* here in the first place. We only use ICScript::jitScript_ to:
a) Tell whether the ICScript is inlined, which can be done more easily by looking at the depth.
b) Find the FallbackICStubSpace for non-inlined ICScripts.

If we use the depth to tell when an ICScript is inlined, then we don't need a pointer to find the owning JitScript (and therefore its stub space) for non-inlined ICScripts. Non-inlined ICScripts are embedded inside a JitScript, so we can compute the offset directly.

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/4d191a3f6f10
Remove ICScript::jitScript_ r=jandem

Comment 6

[Iain Ireland [:iain]]

Attachment: Bug 1661728: Add testcase r=jandem

This testcase is a bit fragile to changes in warmup thresholds. It might be nice if we added a testing function to trial-inline a function on-demand.

Comment 7

[Cristian Brindusan [:cbrindusan]]

https://hg.mozilla.org/mozilla-central/rev/4d191a3f6f10

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/9ec978a54e8d
Add testcase r=jandem

Comment 9

[Bogdan Tara[:bogdan_tara | bogdant]]

https://hg.mozilla.org/mozilla-central/rev/9ec978a54e8d