799313 - IonMonkey: StackIter might not correctly iterate when there is an ion::FastInvoke on the stack.

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect)

Description

[Nicolas B. Pierron [:nbp]]

+++ This bug was initially created as a clone of Bug #798792 +++

(In reply to David Anderson [:dvander] from Bug #798792 comment #3)
> As of right now, there are three states for js::StackFrame, relevant to
> IonMonkey:
>  (1) callingIntoIon: the frame is *not* running in IM, and there is another
> IonActivation.
> 
>  (2) runningInIon: the frame *is* running in IM, and there is another
> IonActivation.
> 
> The third case is an edge case present in ion::FastInvoke, whereby a JM ->
> Ion -> native -> Ion sequence can require pushing 2+ activations for a
> single StackFrame.

This last case is not handle in StackIter and we need to ensure that are iterating frames in the correct order.  My guess is that with the current implementation we are iterating over the native, then the outer-most Ion activation, then anything before the first Ion activation, then potentially the first Ion activation (off-by-one symptoms).

One test case template where this could be shown is by using f.arguments, like (with --no-jm):

var j = 0;
function g() {
  assertEq(j, f.arguments[0]);
}
function f(i) {
  j = i;
  if (i < 100)
    f(i++);
  else {
    for (var k = 0; k < i; k++)
      // do a FastInvoke and call in g.
  }
}

f(0);

Comment 1

[Pablo]

Hi Nicolas, Could you please let us know if this is still an issue? can close it?

thanks

Comment 2

[Nicolas B. Pierron [:nbp]]

JägerMonkey being removed, I presume this bug can safely be closed, as this bug is specific to a problem between JägerMonkey and IonMonkey, as mentioned in comment 0.