Closed
Bug 1514625
Opened 6 years ago
Closed 6 years ago
Assertion failure: !osrBlock_, at js/src/jit/MIRGraph.h:809
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
RESOLVED
FIXED
mozilla66
Tracking | Status | |
---|---|---|
firefox-esr60 | --- | unaffected |
firefox64 | --- | wontfix |
firefox65 | --- | wontfix |
firefox66 | --- | fixed |
People
(Reporter: decoder, Assigned: jandem)
References
Details
(4 keywords, Whiteboard: [jsbugmon:update])
Attachments
(1 file)
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
Updated•6 years ago
|
Whiteboard: [jsbugmon:update,bisect] → [jsbugmon:update]
Comment 1•6 years ago
|
||
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 | ||
Updated•6 years ago
|
Assignee: nobody → jdemooij
Status: NEW → ASSIGNED
Flags: needinfo?(jdemooij)
Assignee | ||
Comment 3•6 years ago
|
||
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
Comment 5•6 years ago
|
||
bugherder |
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla66
Comment 6•6 years ago
|
||
Is there a user impact which justifies backport consideration here?
status-firefox64:
--- → wontfix
status-firefox65:
--- → affected
status-firefox-esr60:
--- → unaffected
Flags: needinfo?(jdemooij)
Flags: in-testsuite+
Assignee | ||
Comment 7•6 years ago
|
||
(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.
Description
•