IonMonkey: OSI does not work with OOL VM-calls

RESOLVED FIXED

Status

()

Core
JavaScript Engine
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: jandem, Assigned: cdleary)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

6 years ago
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.
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.
Assignee: general → christopher.leary
Status: NEW → ASSIGNED
Gary may have found a simpler testcase in Bug 716743.
Blocks: 716624
Depends on: 722238
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.