1143920 - Assertion failure: !has(tmp), at js/src/jit/RegisterSets.h:392

Status: RESOLVED DUPLICATE of bug 1143011

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

The following testcase crashes on mozilla-central revision 436686833af0 (build with --enable-optimize --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --disable-tests --enable-debug, run with --ion-check-range-analysis --baseline-eager):

var expect = '';
test();
function test() {
  function F() {} 
  F.prototype = []; 
  expect = .065;
  var x = new F(); 
  x.length = expect;
  test ();
}



Backtrace:

Program received signal SIGSEGV, Segmentation fault.
0x0000000000894c1d in add (reg=..., this=0x7ffffffcbe68) at js/src/jit/RegisterSets.h:392
#0  0x0000000000894c1d in add (reg=..., this=0x7ffffffcbe68) at js/src/jit/RegisterSets.h:392
#1  add (reg=..., this=0x7ffffffcbe60) at js/src/jit/RegisterSets.h:608
#2  add (any=..., this=0x7ffffffcbe60) at js/src/jit/RegisterSets.h:612
#3  add (reg=..., this=0x7ffffffcbe60) at js/src/jit/RegisterSets.h:630
#4  GenerateCallSetter (masm=..., attacher=..., obj=..., obj@entry=..., holder=..., holder@entry=..., shape=..., shape@entry=..., strict=<optimized out>, object=..., value=..., failure=failure@entry=0x7ffffffcbf30, liveRegs=..., returnAddr=returnAddr@entry=0x7ffff7e4f25c, ion=0x1ba3cc0, cx=0x1a0d3d0) at js/src/jit/IonCaches.cpp:2475
#5  0x00000000008c7bf6 in js::jit::SetPropertyIC::attachCallSetter (this=this@entry=0x1ba3ed0, cx=cx@entry=0x1a0d3d0, outerScript=..., outerScript@entry=..., ion=ion@entry=0x1ba3cc0, obj=obj@entry=..., holder=..., holder@entry=..., shape=shape@entry=..., returnAddr=0x7ffff7e4f25c) at js/src/jit/IonCaches.cpp:2669
#6  0x00000000008c8f09 in js::jit::SetPropertyIC::update (cx=0x1a0d3d0, outerScript=..., cacheIndex=<optimized out>, obj=..., value=...) at js/src/jit/IonCaches.cpp:3104
#7  0x00007ffff7fea123 in ?? ()
#8  0x0000000000000000 in ?? ()
rax	0x0	0
rbx	0x7ffffffcbe60	140737488141920
rcx	0x7ffff6ca53cd	140737333842893
rdx	0x0	0
rsi	0x7ffff6f7a9d0	140737336814032
rdi	0x7ffff6f791c0	140737336807872
rbp	0x7ffffffcbed0	140737488142032
rsp	0x7ffffffcbda0	140737488141728
r8	0x7ffff7fe0780	140737354008448
r9	0x6372732f736a2f6c	7165916604736876396
r10	0x7ffffffcbb60	140737488141152
r11	0x7ffff6c27960	140737333328224
r12	0x2	2
r13	0x7fff7fff7ffe7fff	9223231297218838527
r14	0x7ffffffcbe90	140737488141968
r15	0x7ffffffcbfc0	140737488142272
rip	0x894c1d <GenerateCallSetter(js::jit::MacroAssembler&, js::jit::IonCache::StubAttacher&, JS::HandleObject, JS::HandleObject, js::HandleShape, bool, js::jit::Register, js::jit::ConstantOrRegister, js::jit::Label*, js::jit::RegisterSet, void*, js::jit::IonScript*, JSContext*)+3149>
=> 0x894c1d <GenerateCallSetter(js::jit::MacroAssembler&, js::jit::IonCache::StubAttacher&, JS::HandleObject, JS::HandleObject, js::HandleShape, bool, js::jit::Register, js::jit::ConstantOrRegister, js::jit::Label*, js::jit::RegisterSet, void*, js::jit::IonScript*, JSContext*)+3149>:	movl   $0x188,0x0
   0x894c28 <GenerateCallSetter(js::jit::MacroAssembler&, js::jit::IonCache::StubAttacher&, JS::HandleObject, JS::HandleObject, js::HandleShape, bool, js::jit::Register, js::jit::ConstantOrRegister, js::jit::Label*, js::jit::RegisterSet, void*, js::jit::IonScript*, JSContext*)+3160>:	callq  0x4046a0 <abort@plt>


I'm marking this as s-s because it's a range analysis check failure and the assertion has to do with registers.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Dup of bug 1142993, I bet.

Comment 2

[Carsten Book [:Tomcat]]

(In reply to Not doing reviews right now from comment #1)
> Dup of bug 1142993, I bet.

yeah i guess thats bug 1142993 and unfortunately also on live sites

Comment 3

[Christian Holler (:decoder)]

JSBugMon: The testcase found in this bug no longer reproduces (tried revision 008b3f65a7e0).
JSBugMon: Bisection requested, result:
=== Treeherder Build Bisection Results by autoBisect ===

The "good" changeset has the timestamp "20150311134821" and the hash "beb831c0028b".
The "bad" changeset has the timestamp "20150311135424" and the hash "cff616142313".

Likely regression window: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=beb831c0028b&tochange=cff616142313

Comment 4

[Nicolas B. Pierron [:nbp]]

I cannot reproduce this issue with the latest WIP patches from Bug 1143011.

Before opening this bug we should double check that if this is an issue in the RegisterSet or an issue in the IC.

Comment 5

[Nicolas B. Pierron [:nbp]]

(In reply to Nicolas B. Pierron [:nbp] from comment #4)
> I cannot reproduce this issue with the latest WIP patches from Bug 1143011.

Scratch that, I cannot even reproduce this issue without my patches. :(

Comment 6

[Christian Holler (:decoder)]

JSBugMon: Fix Bisection requested, result:
Due to skipped revisions, the first good revision could be any of:
changeset:   https://hg.mozilla.org/mozilla-central/rev/b2904e8f07e7
user:        Nicolas B. Pierron
date:        Sat Mar 28 01:08:12 2015 +0100
summary:     Bug 1143011 - Extract the has/add/take logic out of the register sets to distinguish between allocatable and live sets. r=jandem,Waldo

changeset:   https://hg.mozilla.org/mozilla-central/rev/509282768033
user:        Nicolas B. Pierron
date:        Sat Mar 28 01:08:12 2015 +0100
summary:     Bug 1143011 - Use AllocatableSet or LiveSet for all register set uses. r=jandem

This iteration took 160.073 seconds to run.

Comment 7

[Nicolas B. Pierron [:nbp]]

(In reply to Christian Holler (:decoder) from comment #6)
> JSBugMon: Fix Bisection requested, result:
> Due to skipped revisions, the first good revision could be any of:
> changeset:   https://hg.mozilla.org/mozilla-central/rev/b2904e8f07e7
> summary:     Bug 1143011 - Extract the has/add/take logic out of the
> register sets to distinguish between allocatable and live sets.
> r=jandem,Waldo
> 
> changeset:   https://hg.mozilla.org/mozilla-central/rev/509282768033
> summary:     Bug 1143011 - Use AllocatableSet or LiveSet for all register
> set uses. r=jandem

Yes, this was expected.

Basically this means that this bug is was a false positive caused by the mix of 2 different register policy.  Bug 1143011 distinguish these 2 policies, and thus fix this issue.