Last Comment Bug 655991 - TI: Assertion failure: frame not in stack space, at vm/Stack.cpp:273
: TI: Assertion failure: frame not in stack space, at vm/Stack.cpp:273
Status: RESOLVED FIXED
: assertion, testcase
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: Trunk
: x86_64 Linux
: -- critical (vote)
: ---
Assigned To: general
:
Mentors:
Depends on:
Blocks: infer-regress langfuzz
  Show dependency treegraph
 
Reported: 2011-05-10 05:25 PDT by Christian Holler (:decoder)
Modified: 2011-08-05 00:54 PDT (History)
4 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
shell testcase, unpack, chdir and run main.js with options "-n -m -a" (631 bytes, application/x-compressed-tar)
2011-05-10 05:25 PDT, Christian Holler (:decoder)
no flags Details

Description Christian Holler (:decoder) 2011-05-10 05:25:46 PDT
Created attachment 531302 [details]
shell testcase, unpack, chdir and run main.js with options "-n -m -a"

The attached testcase asserts on TI revision 32e8c937a409 (run main.js with -m -n -a),
tested on 64 bit.
Comment 1 Brian Hackett (:bhackett) 2011-05-10 10:23:25 PDT
When getting a new frame in UncachedInlineCall, we would make a local copy of f.regs and repoint cx->regs to that (as the interpreter does).  In the TM branch this is an optimization, but for recompilation and frame expansion in the JM branch this is necessary as we want f.regs to reflect the state when the stub call was made for that f.  The problem was that if checking if we had space for the new frame triggered recompilation / inline frame expansion then the f.regs were being updated but the new cx->regs went stale.  We shouldn't make a local copy of cx->regs until we've checked there is space for the new frame and we are about to (infallibly) push it.  I don't think other places we make local copies of cx->regs have this issue (there are only a few).

http://hg.mozilla.org/projects/jaegermonkey/rev/0df33bc6cc38

Note You need to log in before you can comment on or make changes to this bug.