790479 - IonMonkey: Assertion failure: exprStack < SNAPSHOT_MAX_STACK, at ion/Snapshots.cpp:311

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

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


function inSection(x) {
  return SECT_PREFIX + x + SECT_SUFFIX;
}
try {
status = inSection(1);
} catch(exc1) {}
var obj =
  {
    test: function() {
      (inSection(0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,
            0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,
            0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,
            0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,
            0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,
            0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,
            0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9));
    }
  };
obj.test(5, undefined);

Comment 1

[Christian Holler (:decoder)]

Fixed, BugMon didn't try to use the --ion-eager option on mozilla-central.

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:   106741:6cd206b37176
parent:      106740:b63bb39ed1c0
parent:      103644:a0240c1043ee
user:        David Anderson
date:        Wed Aug 29 17:51:24 2012 -0700
summary:     Merge from mozilla-central.

Oops! We didn't test rev b63bb39ed1c0, a parent of the blamed revision! Let's do that now.
Rev b63bb39ed1c0: Found cached shell...    Testing... [Uninteresting] It didn't crash. (0.366 seconds)
good (not interesting) 
As expected, the parent's label is the opposite of the blamed rev's label.

Oops! We didn't test rev a0240c1043ee, a parent of the blamed revision! Let's do that now.
We did not test rev a0240c1043ee because it is not a descendant of either 4ceb3e9961e4 or fdfaef738a00.
Rev a0240c1043ee: Found cached shell...    Testing... [Uninteresting] It didn't crash. (0.124 seconds)
good (not interesting) 
As expected, the parent's label is the opposite of the blamed rev's label.

Comment 3

[Christian Holler (:decoder)]

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

Comment 4

[Christian Holler (:decoder)]

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

The first good revision is:
changeset:   109714:03bc788fd004
user:        Nicolas B. Pierron
date:        Mon Oct 08 18:01:21 2012 -0700
summary:     Bug 798913 - Prevent inlining of overflow of arguments. r=dvander

This iteration took 82.362 seconds to run.

Comment 5

[Nicolas B. Pierron [:nbp]]

(In reply to Christian Holler (:decoder) from comment #4)
> JSBugMon: Fix Bisection requested, result:
> autoBisect shows this is probably related to the following changeset:
> 
> The first good revision is:
> changeset:   109714:03bc788fd004
> user:        Nicolas B. Pierron
> date:        Mon Oct 08 18:01:21 2012 -0700
> summary:     Bug 798913 - Prevent inlining of overflow of arguments.
> r=dvander
> 
> This iteration took 82.362 seconds to run.

This is just a side effect of this patch. The underlying issue still exists, and should be illustrated by the following test case which is not supposed to be impacted by the previous patch.

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

function inSection(
  a0, a1, a2, a3, a4, a5, a6, a7, a8, a9,
  b0, b1, b2, b3, b4, b5, b6, b7, b8, b9,
  c0, c1, c2, c3, c4, c5, c6, c7, c8, c9,
  d0, d1, d2, d3, d4, d5, d6, d7, d8, d9,
  e0, e1, e2, e3, e4, e5, e6, e7, e8, e9,
  f0, f1, f2, f3, f4, f5, f6, f7, f8, f9,
  g0, g1, g2, g3, g4, g5, g6, g7, g8, g9,
  h0, h1, h2, h3, h4, h5, h6, h7, h8, h9,
  i0, i1, i2, i3, i4, i5, i6, i7, i8, i9,
  j0, j1, j2, j3, j4, j5, j6, j7, j8, j9,
  k0, k1, k2, k3, k4, k5, k6, k7, k8, k9,
  l0, l1, l2, l3, l4, l5, l6, l7, l8, l9,
  m0, m1, m2, m3, m4, m5, m6, m7, m8, m9,
  n0, n1, n2, n3, n4, n5, n6, n7, n8, n9,
  o0, o1, o2, o3, o4, o5, o6, o7, o8, o9
  ) {
  return;
}

function test() {
  inSection(); // Inline
}
inSection(); // heat up.
test();

Comment 6

[Christian Holler (:decoder)]

JSBugMon: This bug has been automatically confirmed to be still valid (reproduced on revision 22d192c5d1fd).

Comment 7

[Christian Holler (:decoder)]

Wonderful, tracking test from comment 5 then.

Comment 8

[Christian Holler (:decoder)]

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

Comment 9

[Christian Holler (:decoder)]

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

The first good revision is:
changeset:   113494:4f37c3ad5cda
user:        Marty Rosenberg
date:        Fri Nov 16 09:12:49 2012 -0500
summary:     Rather than just infinite looping, or abort compilation on would-be iloops (bug 803470, r=dvander)

This iteration took 103.079 seconds to run.

Comment 10

[Christian Holler (:decoder)]

Marty, is this bug likely a dup of the bug mentioned in comment 9?

Comment 11

[Christian Holler (:decoder)]

Marty, is this bug likely a dup of the bug mentioned in comment 9?

Comment 12

[Marty Rosenberg [:mjrosenb]]

that patch almost certainly did not fix this problem, and the fact that this bug went away makes me afraid of the impact that patch is actually having.  Assuming that there aren't any infinite looping bugs in range analysis, the patch should be a nop.

Comment 13

[Christian Holler (:decoder)]

Here's a newer testcase (revision 7bce868864bf, run with --ion-eager):

writeHeaderToLog(
        0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,
           0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,
           0,1,2,3,4,5,6,7,8,9,0,1,{} & i,3,4,5,6,7,8,9,
           0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,
           0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,
           0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,
           0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8," " < actual
);

Still the same issue I assume because the tests are so similar.

Comment 14

[Christian Holler (:decoder)]

JSBugMon: Cannot process bug: Unknown exception (check manually)

Comment 15

[Jan de Mooij [:jandem]]

Attachment: Patch

Taking this since it's causing a jit-test failure on the BC branch with --no-baseline (I think because I disabled the inlineScript->hasBaselineScript() check when baseline is disabled).

Comment 16

[Jan de Mooij [:jandem]]

Attachment: Patch

Looks like we don't rely on this limit anywhere, so the assert is bogus and the patch removes it.

Comment 17

[Jan de Mooij [:jandem]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/8e42c2f55b94

Comment 18

[Joe Drew (not getting mail)]

https://hg.mozilla.org/mozilla-central/rev/8e42c2f55b94