680684 - "Assertion failure: index < atomMap.length, at /Users/jorendorff/dev/m-i/js/src/jsscript.h:633" with methodjit, single-step mode, exception

Status: RESOLVED DUPLICATE of bug 658491

(Core :: JavaScript Engine, defect)

Description

[Jason Orendorff [:jorendorff]]

Paste the jsapi-test below into jsapi-test/testDebugger.cpp, make, and make check.

It asserts in ic::SetGlobalName trying to figure out what name we're assigning to. It should get "e" but it's trying to fetch the atom from the wrong script, because f.fp() is the frame for the call to f that wasn't removed from the stack when it threw.

Asserts in m-i tip. I thought this might be mozilla-central rev cb456a20aeef, so I checked, and it's not: the test also asserts exactly the same way in the revision just before jsdbg2 landed.

BEGIN_TEST(testDebugger_singleStepThrow)
    {
        CHECK(JS_SetDebugModeForCompartment(cx, cx->compartment, true));
        CHECK(JS_SetInterrupt(rt, onStep, NULL));

        uint32 opts = JS_GetOptions(cx);
        opts |= JSOPTION_METHODJIT | JSOPTION_METHODJIT_ALWAYS;
        opts &= ~JSOPTION_JIT;
        JS_SetOptions(cx, opts);

        CHECK(JS_DefineFunction(cx, global, "setStepMode", setStepMode, 0, 0));
        EXEC("var e;\n"
             "setStepMode();\n"
             "function f() { throw 0; }\n"
             "try { f(); }\n"
             "catch (x) { e = x; }\n");
        return true;
    }

    static JSBool
    setStepMode(JSContext *cx, uintN argc, jsval *vp)
    {
        JSStackFrame *fp = JS_GetScriptedCaller(cx, NULL);
        JS_ASSERT(fp);
        JSScript *script = JS_GetFrameScript(cx, fp);
        JS_ASSERT(script);
        if (!JS_SetSingleStepMode(cx, script, true))
            return false;
        JS_SET_RVAL(cx, vp, JSVAL_VOID);
        return true;
    }

    static JSTrapStatus
    onStep(JSContext *cx, JSScript *script, jsbytecode *pc, jsval *rval, void *closure)
    {
        return JSTRAP_CONTINUE;
    }
END_TEST(testDebugger_singleStepThrow)

Comment 1

[Jason Orendorff [:jorendorff]]

Confusing. js_InternalThrow seems to be doing the right thing, calling ScriptEpilogue, popping f's frame, leaving f.entryFrame as the top frame on the stack, returning
   (the right script)->nativeCodeForPC(the right pc).

It apparently returns to JaegerThrowpoline, which GDB doesn't handle too well, and then--in methodjit code, which GDB also doesn't handle well--we set cx->stack.seg_->regs_->fp_ back to the already-popped frame.

Comment 2

[Jason Orendorff [:jorendorff]]

This has been fixed in TI for months. I'll transplant the fix over to mozilla-inbound today.