The following testcase asserts on mozilla-central revision c360f3d1c00d (run with --no-threads --fuzzing-safe): gczeal(4); var gTestcases = new Array(); function TestCase() { gTestcases[gTc++] = this; } TestCase.prototype.dump = function () { dump(toPrinted(this.description) + toPrinted(this.reason)); } dump = unescape; for ( gTc=0; gTc < gTestcases.length; gTc++ ) {} function jsTestDriverEnd() { for (var i = 0; i < gTestcases.length; i++) gTestcases[i].dump(); } loadFile("for (var idx = 0; idx < 15; ++idx) { new TestCase(); }"); loadFile("function toPrinted(value) { a = Symbol(value); }"); loadFile("for (var idx = 0; idx < 80-32; ++idx) { new TestCase(); }"); for (var idx = 0; idx < 9; ++idx) { loadFile("jsTestDriverEnd();"); } function loadFile(lfVarx) { evaluate(lfVarx, { noScriptRval : true, compileAndGo : true }); }

Marked s-s until triaged because it's a GC-related assertion.

Test case involves Symbol.

I'm going to guess this is related to Symbol.

JSBugMon: The testcase found in this bug no longer reproduces (tried revision 790f41c631cc). JSBugMon: Bisection requested, result: autoBisect shows this is probably related to the following changeset: The first bad revision is: changeset: https://hg.mozilla.org/mozilla-central/rev/cb3487d8700b user: Nicolas B. Pierron date: Thu Jul 24 04:30:50 2014 -0700 summary: Bug 1039607 - Scalar Replacement support dynamic slots. r=h4writer This iteration took 213.019 seconds to run.

Nicolas, Can you have a look at this? Bisect is pointing to a scalar replacement issue.

I will look, but this sounds surprising knowing that the code added by this patch is not supposed to run.

I cannot reproduce this issue on master, with a debug build compiled with clang-3.3. I can reproduce this issue on cb3487d8700b, with a debug build compiled with gcc-4.6. I can reproduce this issue on cb3487d8700b~1, with a debug build compiled with gcc-4.6. As I can reproduce it better, I am trying to find a better regression range.

Sadly, the current test case does not give us the ability to bisect beyond the following commit, as it is using Symbols, and these are not implemented before that. So either this bug is related to the Symbols, or we might hope to find another minimal test case to reproduce this issue. exec: /home/nicolas/mozilla/alternate-dev/js/src/_build/js-c755dc4-dbg-x64-gcc46 --fuzzing-safe js/src/_build/bug1061665.js @evaluate:1:28 ReferenceError: Symbol is not defined db7aa8370b4a901d1376b2be3fc9473f9394fee2 is the first bad commit commit db7aa8370b4a901d1376b2be3fc9473f9394fee2 Author: Jason Orendorff <jorendorff@mozilla.com> Date: Mon Jun 23 10:55:52 2014 -0500 Bug 645416, part 5 - Add the Symbol constructor and Symbol wrapper objects. r=efaust. This exposes a new primitive type to scripts for the first time since JavaScript first shipped in Netscape 2, over 13 years ago. The tests focus on identity, equality, and being able to pass a symbol around as a value. Of course the point of symbols is that they can be property keys, but that will have to wait for a later patch in this series. --HG-- extra : rebase_source : c22cf4b774cca8e7c9f6c757079e054a6eb0f307 PS: mccr8, good guess ;)

autoBisect shows this is probably related to the following changeset: The first good revision is: changeset: https://hg.mozilla.org/mozilla-central/rev/dc115b033048 user: Jason Orendorff date: Mon Sep 15 13:29:28 2014 -0500 summary: Bug 1053676 - Insert GC pre-barriers for slots containing symbols in Ion code. r=terrence. Jason, is bug 1053676 a likely fix?

Can we close this?

Canceling needinfo, Jason needs to decide if the patch in comment 10 fixes the bug (which seems likely, given the name of the patch).

I'm just going to mark this as fixed. Reopen if you disagree.

JSBugMon: This bug has been automatically verified fixed.

Symbols were disabled for Gecko 34 (B2G v2.1), so I assume that bug 1053676 doesn't need backporting to b2g34.