648586 - TI: Crash [@ JSStackFrame::pc] or "Assertion failure: frame not in stack space,"

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

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

Attachment: more information

eval("\
    function a(y){y.x}\
    for each(let d in[\
        ({}),({}),({}),({}),({}),({}),({}),({}),({}),({})\
    ]){\
        try{\
            a(d)\
        }catch(e){}\
    }\
    n\
")

crashes js opt shell on JM changeset a9f916668b29 with -m, -a and -j at JSStackFrame::pc and asserts js debug shell at Assertion failure: frame not in stack space

(not sure if the regressing changeset below is correct)

autoBisect shows this is probably related to the following changeset:

The first bad revision is:
changeset:   64250:0b1dd5e20bb9
user:        Brian Hackett
date:        Thu Mar 31 18:11:41 2011 -0700
summary:     [INFER] Restore stock JM behavior with inference off, bug 647048.

Comment 1

[Brian Hackett [Laid off!]]

This bug is pretty tricky.  When invoking the tracer, it can write on cx->regs->fp (aka f.regs.fp) when bailing, to synthesize any new frames.  It then calls the interpreter with the original entry fp and active deeper fp.  If the interpreter pops that frame it will not be reflected in f.regs.fp, as the interpreter makes a local copy of the regs, and if the interpreter does something that triggers recompilation we will look at the garbage f.regs.fp.

It would be good to maintain the invariant that for all VMFrames f, f.regs.fp is on the stack.  This saves f.regs while the tracer is running in the same way as the interpreter, restoring it once the tracer finishes.

http://hg.mozilla.org/projects/jaegermonkey/rev/a4355f027716

Comment 2

[Christian Holler (:decoder)]

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