Closed Bug 646495 Opened 9 years ago Closed 9 years ago

TI+JM: Assertion failure: !fe->type.isConstant(), at ../methodjit/FrameState-inl.h:484

Categories

(Core :: JavaScript Engine, defect)

defect
Not set

Tracking

()

RESOLVED FIXED

People

(Reporter: jandem, Unassigned)

References

(Blocks 1 open bug)

Details

--
function f() {
    var x = 1;
    var y;
    if (x = y = Math) {}
}
f();
--
$ ./js -a -n -m test.js
Assertion failure: !fe->type.isConstant(), at ../methodjit/FrameState-inl.h:484
Assignee: general → jandemooij
Status: NEW → ASSIGNED
Assignee: jandemooij → general
Status: ASSIGNED → NEW
There is a FrameState invariant that if an entry is a copy of another entry, the two have the same type (this patch adds appropriate assertions to assertValidRegisterState).  In a couple places while making copies, we can learn types for the copied entry (i.e. y is inferred as an int and a copy of x, so x must also be an int), but did not fixup existing copies of the copied entry.

http://hg.mozilla.org/projects/jaegermonkey/rev/2c9b41f384ea
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Duplicate of this bug: 646547
Maybe it would be better for copies to grab their type information from the backing FE?
I think so, yeah.  Would that be better applied to TM and then merged back?
Yeah that seems like it would reduce a bunch of complexity. There are other areas of code that take care to propagate the type when copying which is gross.
As part of bug 618692, I made this change in the JM branch and beefed up frame state/entry assertions so that all entries which are not on the stack or are not active temporaries are invalidated and it is an error to use them (found a few places where we popped entries off the stack and continued to query them).
You need to log in before you can comment on or make changes to this bug.