Assertion failure: !osrBlock_, at js/src/jit/MIRGraph.h:809

RESOLVED FIXED in Firefox 66

Status

()

defect
--
critical
RESOLVED FIXED
7 months ago
7 months ago

People

(Reporter: decoder, Assigned: jandem)

Tracking

(Blocks 1 bug, 4 keywords)

Trunk
mozilla66
x86_64
Linux
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(firefox-esr60 unaffected, firefox64 wontfix, firefox65 wontfix, firefox66 fixed)

Details

(Whiteboard: [jsbugmon:update])

Attachments

(1 attachment)

The following testcase crashes on mozilla-central revision 5c892a6147ae (build with --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --disable-tests --disable-profiling --enable-debug --enable-optimize, run with --fuzzing-safe --ion-offthread-compile=off --ion-eager):

evaluate("");
while (--i >= 0) {
    if (x > 0) {
        continue;
    }
    switch (i) {
        default:
            i(i);
    }
}


Backtrace:

received signal SIGSEGV, Segmentation fault.
js::jit::MIRGraph::setOsrBlock (this=<optimized out>, osrBlock=0x7ffff5fb9900) at js/src/jit/MIRGraph.h:809
#0  js::jit::MIRGraph::setOsrBlock (this=<optimized out>, osrBlock=0x7ffff5fb9900) at js/src/jit/MIRGraph.h:809
#1  js::jit::IonBuilder::newOsrPreheader (this=this@entry=0x7ffff5fb32e0, predecessor=0x7ffff5fb88e0, loopEntry=0x7ffff49df936 "\343\201\326\003", beforeLoopEntry=<optimized out>) at js/src/jit/IonBuilder.cpp:7165
#2  0x0000555556217d43 in js::jit::IonBuilder::visitGoto (this=this@entry=0x7ffff5fb32e0, ins=ins@entry=0x7ffff5faa6e8) at js/src/jit/IonBuilder.cpp:1731
#3  0x0000555556228959 in js::jit::IonBuilder::visitControlInstruction (this=this@entry=0x7ffff5fb32e0, ins=0x7ffff5faa6e8, restarted=restarted@entry=0x7fffffffc4f7) at js/src/jit/IonBuilder.cpp:1854
#4  0x0000555556245376 in js::jit::IonBuilder::traverseBytecode (this=this@entry=0x7ffff5fb32e0) at js/src/jit/IonBuilder.cpp:1562
#5  0x000055555624626e in js::jit::IonBuilder::build (this=this@entry=0x7ffff5fb32e0) at js/src/jit/IonBuilder.cpp:915
#6  0x00005555562539f5 in js::jit::IonCompile (cx=<optimized out>, cx@entry=0x7ffff5f18000, script=<optimized out>, baselineFrame=baselineFrame@entry=0x7fffffffca28, osrPc=osrPc@entry=0x7ffff49df936 "\343\201\326\003", recompile=<optimized out>, optimizationLevel=<optimized out>) at js/src/jit/Ion.cpp:2012
#7  0x000055555625476b in js::jit::Compile (cx=cx@entry=0x7ffff5f18000, script=script@entry=..., osrFrame=osrFrame@entry=0x7fffffffca28, osrPc=osrPc@entry=0x7ffff49df936 "\343\201\326\003", forceRecompile=forceRecompile@entry=false) at js/src/jit/Ion.cpp:2309
#8  0x0000555556255099 in BaselineCanEnterAtBranch (pc=0x7ffff49df936 "\343\201\326\003", osrFrame=0x7fffffffca28, script=..., cx=0x7ffff5f18000) at js/src/jit/Ion.cpp:2500
#9  js::jit::IonCompileScriptForBaseline (cx=<optimized out>, frame=frame@entry=0x7fffffffca28, pc=pc@entry=0x7ffff49df936 "\343\201\326\003") at js/src/jit/Ion.cpp:2563
#10 0x0000555556026688 in js::jit::DoWarmUpCounterFallbackOSR (cx=<optimized out>, frame=0x7fffffffca28, stub=0x7ffff5fa9298, infoPtr=0x7fffffffca00) at js/src/jit/BaselineIC.cpp:768
#11 0x00003cf4e7f38a1d in ?? ()
[...]
#20 0x0000000000000000 in ?? ()
rax	0x555557b74480	93825032209536
rbx	0x7ffff5fb9b78	140737320295288
rcx	0x7ffff6c1c2dd	140737333281501
rdx	0x555556b4eed0	93825015279312
rsi	0x7ffff6eeb770	140737336227696
rdi	0x7ffff6eea540	140737336223040
rbp	0x7fffffffc420	140737488340000
rsp	0x7fffffffc380	140737488339840
r8	0x7ffff6eeb770	140737336227696
r9	0x7ffff7fe6cc0	140737354034368
r10	0x58	88
r11	0x7ffff6b927a0	140737332717472
r12	0x7ffff5fb32e0	140737320268512
r13	0x7ffff5fb9e48	140737320296008
r14	0x0	0
r15	0x7ffff5fb9900	140737320294656
rip	0x555556217cc8 <js::jit::IonBuilder::newOsrPreheader(js::jit::MBasicBlock*, unsigned char*, unsigned char*)+3272>
=> 0x555556217cc8 <js::jit::IonBuilder::newOsrPreheader(js::jit::MBasicBlock*, unsigned char*, unsigned char*)+3272>:	movl   $0x0,0x0
   0x555556217cd3 <js::jit::IonBuilder::newOsrPreheader(js::jit::MBasicBlock*, unsigned char*, unsigned char*)+3283>:	ud2
Whiteboard: [jsbugmon:update,bisect] → [jsbugmon:update]
JSBugMon: Bisection requested, result:
autoBisect shows this is probably related to the following changeset:

The first bad revision is:
changeset:   https://hg.mozilla.org/mozilla-central/rev/c9ee59766684
user:        Jan de Mooij
date:        Mon Jun 11 10:17:58 2018 -0700
summary:     Bug 1467496 - Simplify JSOP_LOOPENTRY handling in IonBuilder. r=bhackett

This iteration took 295.566 seconds to run.
Jan, is bug 1467496 a likely regressor?
Blocks: 1467496
Flags: needinfo?(jdemooij)
Assignee: nobody → jdemooij
Status: NEW → ASSIGNED
Flags: needinfo?(jdemooij)
For a broken loop we used to change CFGLoopEntry to CFGGoto, but that really
complicates IonBuilder. It's simpler to keep the CFGLoopEntry and set a flag
on it.
Pushed by jdemooij@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/10276b98cd16
Clean up and simplify loop entry code in Ion more. r=nbp
Status: ASSIGNED → RESOLVED
Closed: 7 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla66

Is there a user impact which justifies backport consideration here?

Flags: needinfo?(jdemooij)
Flags: in-testsuite+

(In reply to Ryan VanderMeulen [:RyanVM] from comment #6)

Is there a user impact which justifies backport consideration here?

I was wondering about that when I wrote the patch. On the one hand I'd like to uplift this because it simplifies the code and fixes the assertion failure. On the other hand we don't have that much time left this cycle, this code is a bit hard to reason about, and it regressed in Firefox 62 (the underlying bug may be older) so I think we could live with it for another cycle.

Flags: needinfo?(jdemooij)
You need to log in before you can comment on or make changes to this bug.