798792 - Assertion failure: !fp->beginsIonActivation(), at vm/ArgumentsObject.cpp:39

Status: RESOLVED DUPLICATE of bug 797977

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

The following testcase asserts on mozilla-central revision 2da1f2bde40e (run with --ion-eager):


function bar(x, i) {
    foo.arguments[1] = 20;
}
function foo(x, j, n) {
  for (var i = 0; i < n; i++) {
    bar(x, i);
  }
}
var a = foo([1,2,3,4], 3, .03e7 );

Comment 1

[Nicolas B. Pierron [:nbp]]

Ok, here is what is going on:
- foo is compiled with JM (because Ion refuse to compile it due to foo.arguments)
- bar is entered and the flag callingIntoIon is set on foo's StackFrame.
- StackIter fails to recover the right frame.

dvander, any striking idea?  It seems that the no StackFrame is created for handling JM->Ion calls?  Are callingIntoIon frames valid frames on which we should stop?  in which case the assertion is wrong and should only check the runningInIon flag instead of beginsIonActivation.

Comment 2

[Christian Holler (:decoder)]

JSBugMon: Bisection requested, result:
autoBisect shows this is probably related to the following changeset:

The first bad revision is:
changeset:   109340:3b458f4e0f42
user:        Nicolas B. Pierron
date:        Thu Oct 04 23:13:37 2012 -0700
summary:     Bug 792398 - Recover arguments from bailouts. r=luke

This iteration took 96.993 seconds to run.

Comment 3

[David Anderson [:dvander] - inactive, e-mail if emergency]

(In reply to Nicolas B. Pierron [:pierron] [:nbp] from comment #1)
> dvander, any striking idea?  It seems that the no StackFrame is created for
> handling JM->Ion calls?  Are callingIntoIon frames valid frames on which we
> should stop?  in which case the assertion is wrong and should only check the
> runningInIon flag instead of beginsIonActivation.

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.

Comment 4

[Nicolas B. Pierron [:nbp]]

(In reply to David Anderson [:dvander] from comment #3)
> (In reply to Nicolas B. Pierron [:pierron] [:nbp] from comment #1)
> > dvander, any striking idea?  It seems that the no StackFrame is created for
> > handling JM->Ion calls?  Are callingIntoIon frames valid frames on which we
> > should stop?  in which case the assertion is wrong and should only check the
> > runningInIon flag instead of beginsIonActivation.
> 
> 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.

So the frame which has the callingIntoIon flag, can be used by frames which are running under JM.  Which means that this assertion is bogus.

>  (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.

I will open another bug for this one.

Comment 5

[Christian Holler (:decoder)]

JSBugMon: The testcase found in this bug no longer reproduces (tried revision ca3fa3fbe62a).

Comment 6

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Nicolas inadvertently changed the version/target milestone and it confused JSBugMon, so reverting.

Comment 7

[Christian Holler (:decoder)]

JSBugMon: The testcase found in this bug no longer reproduces (tried revision 8e047a9698f0).

Comment 8

[Nicolas B. Pierron [:nbp]]

Sorry, I forgot to update this bug.
I landed a fix for this Bug as part of the assertion refactoring which happened in Bug 797977.

https://hg.mozilla.org/integration/mozilla-inbound/rev/ebeca12019a2