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

RESOLVED FIXED in mozilla24

Status

()

Core
JavaScript Engine
--
critical
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: decoder, Assigned: shu)

Tracking

(Blocks: 2 bugs, {assertion, regression, testcase})

Trunk
mozilla24
x86
Linux
assertion, regression, testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [jsbugmon:update])

Attachments

(2 attachments)

(Reporter)

Description

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

Comment 1

5 years ago
Created attachment 756533 [details]
[crash-signature] Machine-readable crash signature
(Reporter)

Updated

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

Updated

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

Comment 2

5 years ago
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.
(Reporter)

Comment 3

5 years ago
Needinfo from Shu based on comment 2 :)
Flags: needinfo?(shu)
(Assignee)

Comment 4

5 years ago
Created attachment 756666 [details] [diff] [review]
fix

Bah, I knew there was a reason I had the resumeAfter where it was. :P
Assignee: general → shu
Attachment #756666 - Flags: review?(kvijayan)
Flags: needinfo?(shu)
Blocks: 349611, 875957
Keywords: regression
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.
Attachment #756666 - Flags: review?(kvijayan) → review+
(Assignee)

Comment 6

5 years ago
(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.
https://hg.mozilla.org/mozilla-central/rev/71f7b5bd072b
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla24
You need to log in before you can comment on or make changes to this bug.