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

RESOLVED FIXED in Firefox 41

Status

()

Core
JavaScript Engine
--
critical
RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: decoder, Assigned: h4writer)

Tracking

(Blocks: 1 bug, {assertion, regression, testcase})

Trunk
mozilla41
x86_64
Linux
assertion, regression, testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox39 affected, firefox41 fixed)

Details

(Whiteboard: [jsbugmon:update])

Attachments

(2 attachments)

(Reporter)

Description

3 years ago
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>
(Reporter)

Updated

3 years ago
Whiteboard: [jsbugmon:update,bisect] → [jsbugmon:update]
(Reporter)

Comment 1

3 years ago
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
(Reporter)

Comment 2

3 years ago
Repeating the bisection to debug a problem with the BZAPI.
Whiteboard: [jsbugmon:update] → [jsbugmon:update,bisect]
(Reporter)

Updated

3 years ago
Whiteboard: [jsbugmon:update,bisect] → [jsbugmon:update]
(Reporter)

Comment 3

3 years ago
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?
Flags: needinfo?(hv1989)
(Assignee)

Comment 5

3 years ago
(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.
Assignee: nobody → hv1989
Flags: needinfo?(hv1989)
(Assignee)

Comment 6

3 years ago
Created attachment 8612763 [details] [diff] [review]
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.
Attachment #8612763 - Flags: review?(nicolas.b.pierron)
Attachment #8612763 - Flags: review?(nicolas.b.pierron) → review+
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.
Confirmed green post-backout.
(Assignee)

Comment 12

3 years ago
Created attachment 8615903 [details] [diff] [review]
Fix for windows timeouts

Fix the possible iloop!
Attachment #8615903 - Flags: review?(nicolas.b.pierron)
Attachment #8615903 - Flags: review?(nicolas.b.pierron) → review+
https://hg.mozilla.org/mozilla-central/rev/9fcacf4a76ca
Status: NEW → RESOLVED
Last Resolved: 3 years ago
status-firefox41: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla41
Depends on: 1173529
You need to log in before you can comment on or make changes to this bug.