try { x = new Uint8ClampedArray for (a of []) {} (function() { for (a of [,0]) {} const y = "FOO" x.set(x, { valueOf: function() { print(y) } }) })() } catch (e) {} $ ./js-dbg-64-dm-nsprBuild-darwin-ffa83d153080 --fuzzing-safe --no-threads --ion-eager testcase.js $ ./js-dbg-64-dm-nsprBuild-darwin-ffa83d153080 --fuzzing-safe --no-threads --baseline-eager testcase.js FOO Tested this on m-c rev ffa83d153080. My configure flags are: CC="clang -Qunused-arguments" CXX="clang++ -Qunused-arguments" AR=ar AUTOCONF=/usr/local/Cellar/autoconf213/2.13/bin/autoconf213 sh /Users/skywalker/trees/mozilla-central/js/src/configure --target=x86_64-apple-darwin12.5.0 --enable-debug --enable-nspr-build --enable-more-deterministic --with-ccache --enable-gczeal --enable-debug-symbols --disable-tests python -u ~/fuzzing/js/compileShell.py -b "--enable-debug --enable-more-deterministic --enable-nspr-build" -r ffa83d153080 Bisection is running.

This didn't seem to occur before: http://hg.mozilla.org/mozilla-central/rev/3127df59e0dc After this revision, there was an assertion failure that was fixed by: http://hg.mozilla.org/mozilla-central/rev/6ec4eb9786d8 However, that was when this differential testing bug appeared. Thus, I'm not sure if the issue was introduced by rev 3127df59e0dc, rev 6ec4eb9786d8 or something in-between. Setting needinfo? from Boris, who wrote the patch in rev 3127df59e0dc. Please feel free to move this on if appropriate.

All that did was make it possible to ion-compile the function in this testcase at all. Before that, the for-of loop meant ion bailed out. So it's quite likely the bug predates that patch... That said, if I remove the for-of loops from the testcase or replace them with for-in loops, the bug disappears. :( Also, if I replace the first for-of loop with: var iter = [][Symbol.iterator](); var obj = iter.next(); then the bug still exists, but if I do something similar for the second one it goes away. In any case, in the --ion-eager case we do in fact get to the print(y) call but then that throws an exception: ReferenceError: can't access lexical declaration `y' before initialization which suggests that this is more TDZ trouble akin to bug 1111293. Shu, do you have time to look into this one?

I won't have time until after 7/20. At a conference and going on PTO next week. If you want a speedier response someone else would be better.

OK. Jan, any idea who might have time to look at this?

Nevermind, I found it.

Note that we need to still check for SETALIASEDVAR until global consts are fixed.

Oh we should add a test for this though.