Last Comment Bug 715111 - IonMonkey: OSI does not work with OOL VM-calls
: IonMonkey: OSI does not work with OOL VM-calls
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: unspecified
: All All
: -- normal (vote)
: ---
Assigned To: Chris Leary [:cdleary] (not checking bugmail)
:
Mentors:
Depends on: 722238
Blocks: IonOSI 716624
  Show dependency treegraph
 
Reported: 2012-01-04 05:42 PST by Jan de Mooij [:jandem] (PTO until July 31)
Modified: 2012-02-01 18:59 PST (History)
5 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Jan de Mooij [:jandem] (PTO until July 31) 2012-01-04 05:42:37 PST
Noticed this when reducing a v8-crypto correctness bug (it started crashing at some point).

Consider this testcase:
--
function f(o) {
    o.t;
    o.t;
    for(var i=0; i<100; i++) { }
}
function test() {
    var o = {t: 2};
    f(o);
    o.t = {};
    f(o);
}
test();
--
The second time we call f, the GetPropertyCache function invalidates its caller (f). Afaik, this patches the return address of the VM call to go to the bailout thunk.

The problem is that the bailout/resume process expects the registers to be valid, but they are overwritten by the VM call. So we bailout to the interpreter with bogus values on the stack and the second "o.t" crashes, since o is invalid.
Comment 1 Chris Leary [:cdleary] (not checking bugmail) 2012-01-06 22:07:46 PST
Yeah. We get away with the register push on the inline calls because, on an inline call, the register allocator spills all regs across the call. The only registers that will be referred to by the post-call snapshot are those for the return value from the inline call, and those are valid at the point that the invalidator-thunk runs.

In the OOL path case we push the caller-save regs that are live and then perform a VM call via callVM. We then pop the caller-save regs back into their original locations. We're going to have to pass the live register set (from the safepoint, as given in informSafepoint) into the FrameInfo so that we know which registers are on the stack from the invalidation code.
Comment 2 Sean Stangl [:sstangl] 2012-01-10 14:31:59 PST
Gary may have found a simpler testcase in Bug 716743.

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