1181354 - Differential Testing: Different output message involving Uint8ClampedArray

Status: RESOLVED FIXED

(Core :: JavaScript Engine: JIT, defect)

Description

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

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.

Comment 1

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

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.

Comment 2

[Boris Zbarsky [:bzbarsky]]

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?

Comment 3

[Shu-yu Guo [:shu]]

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.

Comment 4

[Boris Zbarsky [:bzbarsky]]

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

Comment 5

[Shu-yu Guo [:shu]]

Attachment: Account for initaliasedlexical in this one weird const cutout in jit::SetProperty.

Nevermind, I found it.

Comment 6

[Shu-yu Guo [:shu]]

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

Comment 7

[Jan de Mooij [:jandem]]

Oh we should add a test for this though.

Comment 8

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/8bd08e459f24

Comment 9

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/8bd08e459f24