654392 - TI: Assertion failure: (uint8*)ic.funGuard.executableAddress() + ic.joinPointOffset == returnAddress, at js/src/methodjit/MethodJIT.cpp:1041

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

The following testcase asserts on TI revision 3062ff7fef83 (run with -m -n -a),
tested on 64 bit:

function enterFunc (funcName) {}
test();
function test()
{
  enterFunc ( "NaN number", "'eeeefghi'.match(/e*/)", new test( "Date.prototype" ));
  function err() {
    return new Error();
  }
  var error = err(s,s,s,s);
}

Comment 1

[Brian Hackett [Laid off!]]

WFM, fixed I think by rev c963b24694cd.  The problem is that FixupArity needs to update the PC if throwing an exception due to a blown JS stack, but to do that it checks an old ncode value against the frame's JIT after the exception has been marked.  Due to lazy standard class initialization, throwing an exception can cause recompilation (might be nice if this couldn't happen), so the ncode value could be stale by the time FixupArity needed to use it to figure out the pc.

This problem was still there for the interpoline patch (above rev), with the added problem that now there might not be any JIT at all when control returns to FixupArity.  So the patch modifies things so that if we are bumping the stack limit and might throw (i.e. not every FixupArity call), we first make regs.pc coherent.

Comment 2

[Christian Holler (:decoder)]

Automatically extracted testcase for this bug was committed:

https://hg.mozilla.org/mozilla-central/rev/efaf8960a929