1139376 - Assertion failure: phi->hasUses() (Missed an unused phi), at js/src/jit/ValueNumbering.cpp:685

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

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>

Comment 1

[Christian Holler (:decoder)]

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

Comment 2

[Christian Holler (:decoder)]

Repeating the bisection to debug a problem with the BZAPI.

Comment 3

[Christian Holler (:decoder)]

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

Comment 4

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Hannes, is bug 1130679 a likely regressor?

Comment 5

[Hannes Verschore [:h4writer]]

(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.

Comment 6

[Hannes Verschore [:h4writer]]

Attachment: Patch

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.

Comment 7

[Hannes Verschore [:h4writer]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/5f2e8622f945

Comment 8

[Ryan VanderMeulen [:RyanVM]]

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

Comment 9

[Ryan VanderMeulen [:RyanVM]]

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.

Comment 10

[Pulsebot]

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

Comment 11

[Ryan VanderMeulen [:RyanVM]]

Confirmed green post-backout.

Comment 12

[Hannes Verschore [:h4writer]]

Attachment: Fix for windows timeouts

Fix the possible iloop!

Comment 13

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/9fcacf4a76ca

Comment 14

[Carsten Book [:Tomcat]]

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