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

RESOLVED DUPLICATE of bug 797977

Status

()

Core
JavaScript Engine
--
critical
RESOLVED DUPLICATE of bug 797977
6 years ago
6 years ago

People

(Reporter: decoder, Unassigned)

Tracking

(Blocks: 1 bug, {assertion, testcase})

Trunk
x86_64
Linux
assertion, testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [jsbugmon:update,ignore])

(Reporter)

Description

6 years ago
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 );
(Reporter)

Updated

6 years ago
Whiteboard: [jsbugmon:update,bisect]
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.
Flags: needinfo?(dvander)
(Reporter)

Updated

6 years ago
Whiteboard: [jsbugmon:update,bisect] → [jsbugmon:update]
(Reporter)

Comment 2

6 years ago
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.
(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.
Flags: needinfo?(dvander)
(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.
Target Milestone: --- → mozilla18
Version: Trunk → Other Branch
Target Milestone: mozilla18 → ---
(Reporter)

Updated

6 years ago
Whiteboard: [jsbugmon:update] → [jsbugmon:update,ignore]
(Reporter)

Comment 5

6 years ago
JSBugMon: The testcase found in this bug no longer reproduces (tried revision ca3fa3fbe62a).
Nicolas inadvertently changed the version/target milestone and it confused JSBugMon, so reverting.
Whiteboard: [jsbugmon:update,ignore] → [jsbugmon:update]
Version: Other Branch → Trunk
(Reporter)

Updated

6 years ago
Whiteboard: [jsbugmon:update] → [jsbugmon:update,ignore]
(Reporter)

Comment 7

6 years ago
JSBugMon: The testcase found in this bug no longer reproduces (tried revision 8e047a9698f0).
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
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 797977
You need to log in before you can comment on or make changes to this bug.