(function() { for each(y in [ {}, String(), {}, String(), '', '', String(), new String(), new String, {} ]) { print(undefined--) } })() asserts js debug shell on TM changeset d446894bc3a6 with -j at Assertion failure: v_ins->isD(), and crashes js opt shell with -j at a weird address: Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x00000608 0x003f8efd in ?? () (gdb) bt #0 0x003f8efd in ?? () #1 0x001a95c6 in js::ExecuteTree () Previous frame inner to this frame (gdb could not unwind past this frame) (gdb) x/i $eip 0x3f8efd: mov %edx,0x608(%eax) (gdb) x/b $edx 0x60b0d8: 0x68 s-s because a weird address seems to be involved.

js::ExecuteTree seems to be on the stack for optimized builds.

regression from when? I'm seeing js::ExecuteTree show up in the 1.9.2 branch, although it could be an independent bug contributing to a bad tree.

Due to cross compile breakage, attached is the regression window.

WFM on tracemonkey branch. Testing on Mac 10.5 to escape the cross-compile breakage, I get: The first bad revision is: changeset: 56651:19f70f8c2b88 user: Boris Zbarsky date: Thu Nov 04 16:37:44 2010 -0400 summary: Bug 605858. Trace inc() for all primitive values, not just numbers. r=dvander The first good revision is: changeset: 57784:fe0e393e3530 user: Boris Zbarsky date: Tue Nov 23 14:08:26 2010 -0500 summary: Bug 613692. Make sure to update what our current value is when doing type conversions inside incHelper. r=dvander