The following testcase asserts on mozilla-central revision 795632f0e4fe (run with --ion-eager): function TestCase(n, d, e, a) {} function reportCompare (expected, actual, description) { var testcase = new TestCase(); } eval("(function() { \ var summary = 'Do not hang/crash |for each| over object with getter set to map';\ var actual = 'No Crash';\ var expect = 'No Crash';\ reportCompare(expect, actual, summary);\ })();"); eval("(function() { TestCase = Object.prototype.toString; })();"); eval("gc(); reportCompare();");

S-s due to gc being involved.

JSBugMon: Bisection requested, result: autoBisect shows this is probably related to the following changeset: The first bad revision is: changeset: 117618:67e44e98555c user: Hannes Verschore date: Fri Jan 04 17:11:32 2013 +0100 summary: Bug 825705: Creating this on caller-side shouldn't query prototype for unknown objects, r=jandem This iteration took 0.502 seconds to run.

Needinfo from Hannes, based on comment 2 :) Possibly dup to bug 827821, as it has the same regressor.

Partially reduced testcase that crashes 32-bit opt shell at js::ToBooleanSlow (likely a null deref?) with --no-jm and asserts similarly. I'll continue to try reducing this testcase.

s = newGlobal(''); function f(code) { try { evalcx(code, s) } catch (e) {} } f("\ options('strict');\ var x;\ y='';\ Object.preventExtensions(this);\ y=new String;\ y.toString=(function(){x=new Iterator});\ "); f("var z;"); f("var z;"); f("var z;"); f("var z;"); f("var z;"); f("var z;"); f("var z;"); f("var z;"); f("var z;"); f("var z;"); f("var z;"); f("var z;"); f("var z;"); f("var z;"); f("var z;"); f("var z;"); f("var z;"); f("var z;"); f("var z;"); f("var z;"); f("var z;"); f("var z;"); f("var z;"); f("var z;"); f("var z;"); f("var z;"); f("var z;"); f("var z;"); f("var z;"); f("var z;"); f("var z;"); f("var z;"); f("var z;"); f("var z;"); f("var z;"); f("var z;"); f("var z;"); f("var z;"); f("var z;"); f("\ Iterator=String.prototype.toUpperCase;\ v=(function(){});\ Object.defineProperty(Function,0,({enumerable:x}));\ ") Reduced version of the testcase in comment 4. Thanks nbp for helping out with reduction. (gdb) x/i $pc => 0x80867ae <js::ToBooleanSlow(JS::Value const&)+30>: mov (%edx),%ecx (gdb) x/b $edx 0xa: Cannot access memory at address 0xa (gdb) x/b $ecx 0xffffff84: Cannot access memory at address 0xffffff84 (gdb) Seems highly likely to be sec-critical since 0xffffff84 is being accessed.

Testcase in comment 5 requires --no-jm and also crashes on 64-bit js shells. It seems to go away with --ion-eager.

taking tracking over to bug 827821