var eCount = 0; var funs = [function () {}, function () {}]; function someElement(a) { ++eCount; var i = (eCount >= 8) ? 1 : 0; return a[i] } var recursionGuard = 0; function recursiveThing() { someElement(funs); if (++recursionGuard % 2) { e1(); } } function e1() { try {} catch (e) {} someElement(funs); recursiveThing() } recursiveThing() gc(); recursiveThing() recursiveThing() asserts js debug shell on IonMonkey changeset 23a84dbb258f with--ion-eager and -a at Assertion failure: refcount_, s-s because this involves gc. Many thanks go out to Jesse for reducing to this from being hundreds of lines long.

This and bug 776687 are fuzzblockers - they should be the ones that create lots of dupes.

autoBisect shows this is probably related to the following changeset: The first bad revision is: changeset: 100934:8ea86b9020a2 user: Nicolas Pierron date: Mon Jul 16 23:19:26 2012 +0200 summary: Bug 772509 - Freeze a compilation output instead of a script. r=bhackett,dvander

Decrement the reference counter only for script which have been incremented before. This bug should only appear when the monitored values is frozen by both a compiled JM function and a compiled Ion function. The second check is failing because the script which has been JM-compiled is also Ion-compiled and cause an additional decref to happen.

Comment on attachment 645493 [details] [diff] [review] Do not invalidate the IonScript when JM is invalidated. Review of attachment 645493 [details] [diff] [review]: ----------------------------------------------------------------- Good catch.

https://hg.mozilla.org/projects/ionmonkey/rev/eef915d5a18f I removed the security-sensitive flag because this bug is fixed before IonMonkey landing in inbound and it only affect IonMonkey.

Backed out due to tbpl failures: https://hg.mozilla.org/projects/ionmonkey/rev/41f66d0e46b3

A testcase for this bug was automatically identified at js/src/jit-test/tests/ion/bug776748.js.