579740 - TM: Crash [@ js::Interpret] or "Assertion failure: LIR type error (start of writer pipeline): arg 1 of 'ldi' is 'immd' which has type float64 (expected int32)"

Status: VERIFIED FIXED

(Core :: JavaScript Engine, defect)

Description

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

for (a = 0; a < 4; a++) {
    new Math.round(0).t
}

crashes js opt shell on TM tip with -j at js::Interpret and asserts js debug shell on TM tip with -j at Assertion failure: LIR type error (start of writer pipeline): arg 1 of 'ldi' is 'immd' which has type float64 (expected int32): 0 (../nanojit/LIR.cpp:2783)

s-s because this is an LIR type error.

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000004
0x0005da5d in js::Interpret ()
(gdb) bt
#0  0x0005da5d in js::Interpret ()
#1  0x0006e68b in js::Execute ()
#2  0x00014b68 in JS_ExecuteScript ()
#3  0x00005dfc in Process ()
#4  0x00009696 in shell ()
#5  0x00009ba7 in main ()
(gdb) x/i $eip
0x5da5d <_ZN2js9InterpretEP9JSContext+7053>:    cmp    %eax,0x4(%ecx)
(gdb) x/b $eax
0x199020 <js_ArrayClass>:       0xc9
(gdb) x/b $ecx
0x0:    Cannot access memory at address 0x0

Comment 1

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

I couldn't use the technique in bug 558633 comment #6 to get more LIR spew, it gives me a Assertion failure: rmask(rr) & FpRegs (../nanojit/Nativei386.cpp:2154)

Comment 2

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

autoBisect shows this is probably related to the following changeset:

The first bad revision is:
changeset:   46286:839073dc9b77
user:        David Anderson
date:        Mon Jun 28 14:49:12 2010 -0500
summary:     Bug 567577 - `new Math.sin` is NaN, not an object, in interpreter only. r=Waldo.

Comment 3

[Nicholas Nethercote [inactive]]

(In reply to comment #1)
> I couldn't use the technique in bug 558633 comment #6 to get more LIR spew, it
> gives me a Assertion failure: rmask(rr) & FpRegs
> (../nanojit/Nativei386.cpp:2154)

Gary, if you use TMFLAGS=recorder instead of TMFLAGS=readlir that might work.  TMFLAGS=recorder prints out the LIR in an earlier stage of compilation, and that assert occurs during assembly which is the last stage of compilation.

Comment 4

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

Attachment: Console output

(In reply to comment #3)
> Gary, if you use TMFLAGS=recorder instead of TMFLAGS=readlir that might work. 
> TMFLAGS=recorder prints out the LIR in an earlier stage of compilation, and
> that assert occurs during assembly which is the last stage of compilation.

Thanks for the suggestion, Nick, hope this helps the devs.

Comment 5

[Robert Sayre]

any update on this?

Comment 6

[David Anderson [:dvander] - inactive, e-mail if emergency]

Attachment: fix

Hrm... looks like some kind of existing bug. It can't be right that these cases are valid for NEW, APPLY.

Comment 7

[Jason Orendorff [:jorendorff]]

Comment on attachment 462650 [details] [diff] [review]
fix

OK, but please land it on TM (the patch will need a tweak due to recentish changes there).

Comment 8

[David Anderson [:dvander] - inactive, e-mail if emergency]

http://hg.mozilla.org/tracemonkey/rev/0e1d9698a6ac

Comment 9

[Robert Sayre]

http://hg.mozilla.org/mozilla-central/rev/0e1d9698a6ac

Comment 10

[Christian Holler (:decoder)]

Tracer has been long gone on trunk, marking verified.

Comment 11

[Christian Holler (:decoder)]

A testcase for this bug was automatically identified at js/src/jit-test/tests/basic/bug579740.js.