655950 - TI: "Assertion failure: isObject(),"

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

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

function f() {
    try {
        (new {
            x: function() {}
        }.x)();
    } catch (e) {}
}
for (var i = 0;; i++) {
    f();
}

asserts js debug shell on JM changeset 32e8c937a409 with -m, -j and -n at Assertion failure: isObject(),

(gdb) bt
#0  0xf7fdf430 in __kernel_vsyscall ()
#1  0xf7fb5ba0 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:42
#2  0x081fdc65 in JS_Assert (s=0x83c66e4 "isObject()", file=0x83c668c "/home/fuzz1/Desktop/jsfunfuzz-dbg-32-jm-69153-32e8c937a409/compilePath/js/src/jsvalue.h", ln=619)
    at /home/fuzz1/Desktop/jsfunfuzz-dbg-32-jm-69153-32e8c937a409/compilePath/js/src/jsutil.cpp:89
#3  0x0805a03b in js::Value::toObject (this=0xf76e40b0) at /home/fuzz1/Desktop/jsfunfuzz-dbg-32-jm-69153-32e8c937a409/compilePath/js/src/jsvalue.h:619
#4  0x080f24d5 in js::CallReceiver::callee (this=0xffffa568) at /home/fuzz1/Desktop/jsfunfuzz-dbg-32-jm-69153-32e8c937a409/compilePath/js/src/vm/Stack.h:171
#5  0x0812685a in js::Invoke (cx=0x84e2028, argsRef=..., option=js::INVOKE_NORMAL) at /home/fuzz1/Desktop/jsfunfuzz-dbg-32-jm-69153-32e8c937a409/compilePath/js/src/jsinterp.cpp:629
#6  0x083994fd in js::Interpret (cx=0x84e2028, entryFrame=0xf76e4078, inlineCallCount=0, interpMode=js::JSINTERP_SAFEPOINT)
    at /home/fuzz1/Desktop/jsfunfuzz-dbg-32-jm-69153-32e8c937a409/compilePath/js/src/jsinterp.cpp:4746
#7  0x08353797 in js_InternalInterpret (returnData=0xf6e9c9d8, returnType=0xffff0007, returnReg=0x82b6540, f=...)
    at /home/fuzz1/Desktop/jsfunfuzz-dbg-32-jm-69153-32e8c937a409/compilePath/js/src/methodjit/InvokeHelpers.cpp:1612
#8  0x082b6518 in JaegerInterpoline () at /home/fuzz1/Desktop/jsfunfuzz-dbg-32-jm-69153-32e8c937a409/compilePath/js/src/methodjit/MethodJIT.cpp:152
#9  0x000f4240 in ?? ()
#10 0x00000000 in ?? ()

Comment 1

[Brian Hackett [Laid off!]]

Hmm, I can't repro on the given changeset in either 32 bit or 64 bit.

Comment 2

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

(In reply to comment #1)
> Hmm, I can't repro on the given changeset in either 32 bit or 64 bit.

Tested on Linux 32-bit, but if it continues to be unreproducible, perhaps WFM then.

Comment 3

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

I still can reproduce this on JM changeset fd1abc43d698 with -m, -j and -n on a 32-bit Linux shell when the testcase is passed in as a CLI argument.

Comment 4

[Jan de Mooij [:jandem]]

Attachment: Patch

GCC on 32-bit Linux didn't like the uint64 cast. If returnData was 0xffff0007, rvalBits ended up with 0xffffffff type tag. I also swapped the operands because I think it's more readable now that we use (uint32).

This fixes the test in coment 0 and most jit-tests (one failure left).

Comment 5

[Jan de Mooij [:jandem]]

http://hg.mozilla.org/projects/jaegermonkey/rev/8cf9c7a55d8d

Comment 10

[Christian Holler (:decoder)]

Automatically extracted testcase for this bug was committed:

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