The following testcase crashes on mozilla-central revision c5b90c003be8 (build with --enable-optimize --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --enable-debug, run with --ion-eager --no-threads): (function() { var $10=0; while (1) { switch (stack.label & 2) { case 1: return $8|0; case 49: if ($10) {} } } })()() Backtrace: Program received signal SIGSEGV, Segmentation fault. 0x00000000009d27e6 in loopHasOptimizablePhi (header=0x1b35278, this=0x7fffffffbec0) at js/src/jit/ValueNumbering.cpp:685 685 MOZ_ASSERT(phi->hasUses(), "Missed an unused phi"); #0 0x00000000009d27e6 in loopHasOptimizablePhi (header=0x1b35278, this=0x7fffffffbec0) at js/src/jit/ValueNumbering.cpp:685 #1 js::jit::ValueNumberer::visitDominatorTree (this=this@entry=0x7fffffffbec0, dominatorRoot=dominatorRoot@entry=0x1b349b8) at js/src/jit/ValueNumbering.cpp:1007 #2 0x00000000009d28e3 in js::jit::ValueNumberer::visitGraph (this=this@entry=0x7fffffffbec0) at js/src/jit/ValueNumbering.cpp:1038 #3 0x00000000009d2a8e in js::jit::ValueNumberer::run (this=0x7fffffffbec0, updateAliasAnalysis=<optimized out>) at js/src/jit/ValueNumbering.cpp:1109 #4 0x000000000089e84b in js::jit::OptimizeMIR (mir=mir@entry=0x1b33eb8) at js/src/jit/Ion.cpp:1374 #5 0x00000000008b7af0 in js::jit::CompileBackEnd (mir=mir@entry=0x1b33eb8) at js/src/jit/Ion.cpp:1606 #6 0x00000000008b854f in js::jit::IonCompile (cx=cx@entry=0x1a2e490, script=0x7ffff7e5e1f0, baselineFrame=baselineFrame@entry=0x0, osrPc=0x0, constructing=false, recompile=<optimized out>, optimizationLevel=js::jit::Optimization_Normal) at js/src/jit/Ion.cpp:1984 #7 0x00000000008b88fb in js::jit::Compile (cx=cx@entry=0x1a2e490, script=..., script@entry=0x7ffff7e5e1f0, osrFrame=osrFrame@entry=0x0, osrPc=osrPc@entry=0x0, constructing=<optimized out>, forceRecompile=forceRecompile@entry=false) at js/src/jit/Ion.cpp:2138 #8 0x00000000008b8d32 in js::jit::CanEnter (cx=0x1a2e490, state=...) at js/src/jit/Ion.cpp:2277 #9 0x00000000006019b8 in js::RunScript (cx=cx@entry=0x1a2e490, state=...) at js/src/vm/Interpreter.cpp:424 #10 0x000000000060225a in js::Invoke (cx=cx@entry=0x1a2e490, args=..., construct=construct@entry=js::NO_CONSTRUCT) at js/src/vm/Interpreter.cpp:517 #11 0x0000000000603164 in js::Invoke (cx=0x1a2e490, thisv=..., fval=..., argc=0, argv=<optimized out>, rval=JSVAL_VOID) at js/src/vm/Interpreter.cpp:554 #12 0x00000000009b39d9 in js::jit::InvokeFunction (cx=0x1a2e490, obj=(JSObject * const) 0x7ffff7e73100 [object Function <unnamed>], argc=0, argv=0x7fffffffcf80, rval=0x7fffffffcf40) at js/src/jit/VMFunctions.cpp:75 #13 0x00007ffff7f71359 in ?? () #14 0x0000000000000000 in ?? () rax 0x0 0 rbx 0x1b349b8 28527032 rcx 0x7ffff6cb2f30 140737333899056 rdx 0x0 0 rsi 0x7ffff6f86a80 140737336863360 rdi 0x7ffff6f85180 140737336856960 rbp 0x7fffffffb9a0 140737488337312 rsp 0x7fffffffb930 140737488337200 r8 0x7ffff7fe8740 140737354041152 r9 0x72746e65632d616c 8247338199356891500 r10 0x7fffffffb6c0 140737488336576 r11 0x7ffff6c3a940 140737333406016 r12 0x7fffffffbec0 140737488338624 r13 0x1b33d50 28523856 r14 0x1b35768 28530536 r15 0x1b357b8 28530616 rip 0x9d27e6 <js::jit::ValueNumberer::visitDominatorTree(js::jit::MBasicBlock*)+1110> => 0x9d27e6 <js::jit::ValueNumberer::visitDominatorTree(js::jit::MBasicBlock*)+1110>: movl $0x2ad,0x0 0x9d27f1 <js::jit::ValueNumberer::visitDominatorTree(js::jit::MBasicBlock*)+1121>: callq 0x404ac0 <abort@plt>

JSBugMon: Bisection requested, result: === Treeherder Build Bisection Results by autoBisect === The "good" changeset has the timestamp "20150227163831" and the hash "490afdad9ba1". The "bad" changeset has the timestamp "20150227165248" and the hash "31d7b208abd1". Likely regression window: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=490afdad9ba1&tochange=31d7b208abd1

Repeating the bisection to debug a problem with the BZAPI.

JSBugMon: Bisection requested, result: === Treeherder Build Bisection Results by autoBisect === The "good" changeset has the timestamp "20150227163831" and the hash "490afdad9ba1". The "bad" changeset has the timestamp "20150227165248" and the hash "31d7b208abd1". Likely regression window: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=490afdad9ba1&tochange=31d7b208abd1

Hannes, is bug 1130679 a likely regressor?

(In reply to Gary Kwong [:gkw] [:nth10sd] from comment #4) > Hannes, is bug 1130679 a likely regressor? Quickly had a look. I doubt bug 1130679 is the cause. Issue seems to be more of a GVN issue where that bug is a range analysis change. So my guess is that the changes there made it easier to come up with a testcase showing this new issue. Taking.

The regression range is correct. It was caused by the given patch. In GVN we can set a MPhi to "GuardRangeBailouts". VN assumed that an MPhi is always removable if it has no uses. Which is correct. GuardRangeBailouts can in that case always be hoisted to the uses. So I made sure tryRemovingGuards also does this + I made the assert not fail in such cases.

Retriggers confirm that this was the cause of a big spike in Win8 web-platform-test timeouts. Backed out. https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&fromchange=b0bc0aa63816&tochange=5f2e8622f945&filter-searchStr=Windows%20x64%20W%282%29

There were also a couple similar-looking timeouts on OSX 10.10, but nowhere near the same frequency as Win8. Both are x64 if that matters.

Backout: https://hg.mozilla.org/integration/mozilla-inbound/rev/202024e27e3b

Confirmed green post-backout.

Fix the possible iloop!