878038 - Assertion failure: exprStack == js_ReconstructStackDepth(GetIonContext()->cx, script, bailPC), at ion/shared/CodeGenerator-shared.cpp:272

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

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


function funapply6( ... arguments    )  {
  return 1;
}
function test6(i) {
  return funapply6(i,1,2,3);
}
test6(89)[0]
test6(0.2)

Comment 1

[Christian Holler (:decoder)]

Attachment: [crash-signature] Machine-readable crash signature

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:   133356:e7a5e3d66eb4
user:        Shu-yu Guo
date:        Wed May 29 16:32:39 2013 -0700
summary:     Bug 875957 - Record argument types in the element types of the rest array in Ion and Baseline. (r=djvj)

This iteration took 329.374 seconds to run.

Comment 3

[Christian Holler (:decoder)]

Needinfo from Shu based on comment 2 :)

Comment 4

[Shu-yu Guo [:shu]]

Attachment: fix

Bah, I knew there was a reason I had the resumeAfter where it was. :P

Comment 5

[Kannan Vijayan [:djvj]]

Comment on attachment 756666 [details] [diff] [review]
fix

Review of attachment 756666 [details] [diff] [review]:
-----------------------------------------------------------------

r+ing it since the change is correct.  But can you explain what was going wrong with the previous version, and add a comment to the resumeAfter loop explaining why they're happening after all the store instructions are added, instead of as they are added?  I don't understand what specifically the bug was.

Comment 6

[Shu-yu Guo [:shu]]

(In reply to Kannan Vijayan [:djvj] from comment #5)
> Comment on attachment 756666 [details] [diff] [review]
> fix
> 
> Review of attachment 756666 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> r+ing it since the change is correct.  But can you explain what was going
> wrong with the previous version, and add a comment to the resumeAfter loop
> explaining why they're happening after all the store instructions are added,
> instead of as they are added?  I don't understand what specifically the bug
> was.

Added, pasted below.

    // The reason this loop of resumeAfters is here and not above is because
    // resume points check the stack depth at its callsite in IonBuilder
    // matches the expected stack depth at the point where we would bail back
    // to in the interpreter. So we can't call resumeAfter until after we have
    // pushed the array onto the stack.

Comment 7

[Shu-yu Guo [:shu]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/71f7b5bd072b

Comment 8

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/71f7b5bd072b