568826 - TM: "Assertion failed: LIR type error (start of writer pipeline): arg 4 of 'calli' is 'ldi' which has type int32 (expected float64): 0 ("

Status: VERIFIED FIXED

(Core :: JavaScript Engine, defect)

Description

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

NaN = []
for (var a = 0; a < 2; ++a) {
    if (a == 1) {
        for each(e in [NaN, Infinity, NaN]) {}
    }
}

asserts js debug shell on TM tip with -j at Assertion failed: LIR type error (start of writer pipeline): arg 4 of 'calli' is 'ldi' which has type int32 (expected float64): 0 (../nanojit/LIR.cpp:2642)

s-s because this is a LIR type error. Assuming [sg:critical?] unless otherwise noted.

Comment 1

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

autoBisect shows it is probably related to the following regression window:

http://hg.mozilla.org/tracemonkey/pushloghtml?fromchange=37083&tochange=37ee0e47774d

I have no idea if it involves bug 463137 or bug 521692.

Comment 2

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

More accurately:

http://hg.mozilla.org/tracemonkey/pushloghtml?fromchange=7543bdf1d37e&tochange=37ee0e47774d

Comment 3

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

Extra LIR info from technique in bug 558633 comment #6 :

=== BEGIN Initial LIR ===
  00: start
  01: ebx = parami 0 ebx
  02: esi = parami 1 esi
  03: edi = parami 2 edi
  04: state = parami 0 ecx
  05: label1:
  06: sp = ldi.o state[8]
  07: rp = ldi.o state[24]
  08: cx = ldi.o state[0]
  09: eos = ldi.o state[12]
  10: eor = ldi.o state[28]
  11: ldi4 = ldi.csro cx[0]
  12: immi1 = immi 0
  13: eqi3 = eqi ldi4, immi1/*0*/
  14: xf4: xf eqi3 -> pc=0x40c7df imacpc=0x0 sp+8 rp+0 (GuardID=001)
  15: globalObj = immi 16785408
  16: $global0 = ldd.o eos[1096]
  17: $stack0 = ldi.s sp[0]
  18: ldi3 = ldi.o $stack0[4]
  19: ~JSSLOT_CLASS_MASK_BITS = immi -4
  20: andi4 = andi ldi3, ~JSSLOT_CLASS_MASK_BITS/*-4*/
  21: clasp = immi 2079104
  22: guard(class is Iterator) = eqi andi4, clasp/*2079104*/
  23: xf3: xf guard(class is Iterator) -> pc=0x40c7e0 imacpc=0x0 sp+8 rp+0 (GuardID=002)
  24: ldi1 = ldi.c $stack0[16]
  25: cursor = ldi.o ldi1[4]
  26: next = ldi.o cursor[0]
  27: JSVAL_DOUBLE = immi 2
  28: JSVAL_TAGMASK = immi 7
  29: andi3 = andi next, JSVAL_TAGMASK/*7*/
  30: eqi2 = eqi andi3, JSVAL_DOUBLE/*2*/
  31: JSVAL_INT = immi 1
  32: andi2 = andi next, JSVAL_INT/*1*/
  33: ori1 = ori andi2, eqi2
  34: eqi1 = eqi ori1, immi1/*0*/
  35: xt1: xt eqi1 -> pc=0x40c7e0 imacpc=0x0 sp+8 rp+0 (GuardID=003)
  36: js_UnboxDouble1 = calld. #js_UnboxDouble ( next )
  37: sizeof(jsval) = immi 4
  38: addi1 = addi cursor, sizeof(jsval)/*4*/
  39: sti.o ldi1[4] = addi1
  40: std.o eos[1096] = js_UnboxDouble1
  41: ldi2 = ldi.o $stack0[4]
  42: andi1 = andi ldi2, ~JSSLOT_CLASS_MASK_BITS/*-4*/
  43: guard(class is Iterator) = eqi andi1, clasp/*2079104*/
  44: xf2: xf guard(class is Iterator) -> pc=0x40c7e3 imacpc=0x0 sp+8 rp+0 (GuardID=004)
  45: cursor2 = ldi.o ldi1[4]
  46: end = ldi.o ldi1[8]
  47: lti1 = lti cursor2, end
  48: xf1: xf lti1 -> pc=0x40c7e3 imacpc=0x0 sp+8 rp+0 (GuardID=005)
  49: j -> label1
  50: livei state
  51: x1: x  -> pc=0x40c7df imacpc=0x0 sp+8 rp+0 (GuardID=006)
=== END Initial LIR ===

Comment 4

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

Comment 3 was tested on 32-bit debug Mac shell.

Comment 5

[Andreas Gal :gal]

The lir is very helpful. Thanks gary!

Comment 6

[Andreas Gal :gal]

Man, nick's improved asserts for call argument types are _really_ helpful here.

Assertion failed: LIR type error (start of writer pipeline): arg 4 of 'calli' is 'ldq' which has type int64 (expected float64): 0 (../nanojit/LIR.cpp:2642)

Comment 7

[Andreas Gal :gal]

We fail to ignore writing to a read-only property of the global object (NaN). Old and very bad bug. Affects branches.

Comment 8

[Andreas Gal :gal]

Ok, so here is what happens:

We make a NaN property on the global object and assign it []. Since we are assigning, we don't run the resolve hook. This is wrong. We should never be able to make NaN with a different value since its permanent read-only. When we get Infinity shortly thereafter, we run the resolve hook and paint over NaN with the value nan, which is out of sync with the tracker and we die.

A search shows that at least for these global properties we only do this in the shell, not the browser:

http://mxr.mozilla.org/mozilla-central/search?string=JS_ResolveStandardClass&find=&findi=&filter=^[^\0]*%24&hitlimit=&tree=mozilla-central

Comment 9

[Andreas Gal :gal]

Attachment: patch

Comment 10

[Andreas Gal :gal]

http://hg.mozilla.org/tracemonkey/rev/92a66e7519b7

Comment 11

[Robert Sayre]

http://hg.mozilla.org/mozilla-central/rev/92a66e7519b7

Comment 12

[LegNeato]

Any hope for branch patches for this?

Comment 13

[Andreas Gal :gal]

This is shell only (neither file is linked into the browser). Don't block on it. Also, shell workers are not in 1.9.2 or 1.9.1.

Comment 14

[LegNeato]

Ok, thanks!

Comment 15

[Christian Holler (:decoder)]

Tracer has been long gone on trunk, marking verified.

Comment 16

[Christian Holler (:decoder)]

Automatically extracted testcase for this bug was committed:

https://hg.mozilla.org/mozilla-central/rev/efaf8960a929

Comment 17

[Nicholas Nethercote [inactive]]

> Automatically extracted testcase for this bug was committed:
> 
> https://hg.mozilla.org/mozilla-central/rev/efaf8960a929

That's not much help because this bug was in the trace JIT, which is long dead.

Comment 18

[Christian Holler (:decoder)]

(In reply to Nicholas Nethercote [:njn] from comment #17)

> That's not much help because this bug was in the trace JIT, which is long
> dead.

See bug 567577 comment 20.