656571 - TI: Crash [@ js::types::TypeCompartment::dynamicAssign] or [@ js::types::HashSetInsertTry]

Status: VERIFIED FIXED

(Core :: JavaScript Engine, defect)

Description

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

function g(code) {
    f = m("(function(){" + code + "})");
    h(f);
}
function m(s) {
    return eval(s);
}
function h(f) {
    try {
        f();
    } catch (r) {}
}
g("");
g("");
g("");
g("\
  for(var z=0;z<7;z++) {\
    w = -\"\"\
  }\
");

crashes js opt shell on JM changeset 2178344055f5 with -m, -a, -j and -n at js::types::TypeCompartment::dynamicAssign but does not seem to cause anything bad in debug shell. Tested on 32-bit Linux shell on Ubuntu 10.10.

(gdb) bt
#0  js::types::TypeCompartment::dynamicAssign (this=0x838e960, cx=0x838e320, obj=0xffff0005, id=137585520, rval=...)
    at /home/fuzz1/Desktop/jsfunfuzz-opt-32-jm-69177-2178344055f5/compilePath/js/src/jsinfer.cpp:2007
#1  0x082f0df6 in void js::mjit::stubs::SetName<0>(js::VMFrame&, JSAtom*) ()
#2  0x08296da4 in js::mjit::ic::SetProp (f=..., pic=0x83d2f04) at /home/fuzz1/Desktop/jsfunfuzz-opt-32-jm-69177-2178344055f5/compilePath/js/src/methodjit/PolyIC.cpp:1846
#3  0xf76d7446 in ?? ()
#4  0x08347ff4 in ?? ()

Comment 1

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

function g(code) {
    f = f1("(function(){" + code + "})");
    f2(f, code);
}
function f1(s) {
    return eval(s);
}
function f2(f, e) {
    try {
        f();
    } catch (r) {}
}
g("");
g("");
g("");
g("\
  for(let x=0;x<5;x++) {\
    w = -false\
  }\
");

seems to be related, crashes 32-bit js opt shell on JM changeset ef1ce31f66b9 with -m, -a and -n at js::types::HashSetInsertTry on 64-bit Ubuntu 10.10.

Comment 2

[Brian Hackett [Laid off!]]

The problem is that if we enter the method JIT at a branch, we don't ensure the frame has a scope chain even if the JIT code will later try to access that field of the frame directly.  One line fix (make sure the fp has a scope chain in EnterMethodJIT).

This recently started showing up on JM because if our initial attempt to compile fails (from '-false') we go into the interpreter and then compile again on the first backedge, before the interpreter has hit a NAME opcode and initialized the scope chain lazily.

Comment 3

[Brian Hackett [Laid off!]]

Fixed in the JM branch as part of rev 0cd135eb71a3.

Comment 4

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

(In reply to comment #3)
> Fixed in the JM branch as part of rev 0cd135eb71a3.

Setting Resolved FIXED.

Comment 5

[Christian Holler (:decoder)]

JSBugMon: This bug has been automatically verified fixed.