1181828 - Differential Testing: Different output message involving cacheEntry

Status: RESOLVED DUPLICATE of bug 1108603

(Core :: JavaScript Engine: JIT, defect)

Description

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

// jsfunfuzz-generated
try {
    t([1])
} catch (e) { print(e) }
// Randomly chosen test: js/src/jit-test/tests/basic/bug1061534.js
try {
    (function() {
        x = cacheEntry("print('foo')");
        evaluate(x, {
            saveBytecode: true
        })
    })()
} catch (e) { print(e); }

$ ./js-dbg-64-dm-nsprBuild-darwin-f34a7120f46b --fuzzing-safe --no-threads --ion-eager testcase.js
ReferenceError: t is not defined
Error: compartment cannot save singleton anymore.

$ ./js-dbg-64-dm-nsprBuild-darwin-f34a7120f46b --fuzzing-safe --no-threads --no-baseline --no-ion testcase.js
ReferenceError: t is not defined
foo

Tested this on m-c rev f34a7120f46b.

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 ~/funfuzz/js/compileShell.py -b "--enable-debug --enable-more-deterministic --enable-nspr-build" -r f34a7120f46b

Comment 1

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

This seems to go back further than m-c rev a459b02a9ca4.

Setting needinfo? from Hannes to diagnose if this is related to IonMonkey.

Comment 2

[Boris Zbarsky [:bzbarsky]]

So getSingletonsAsTemplates() ends up returning false.  

That means someone called setSingletonsAsValues() and the obvious callers are JSOP_OBJECT in the interpreter, the jsop_object case in IonBuilder, and emit_JSOP_OBJECT in baseline.

In this case, we hit emit_JSOP_OBJECT in baseline, where the object is an array.  WE also hit the jsop_object case in IonBuilder, of course.

I think the difference is that in the interp case the JSOP_OBJECT evaluation happens _after_ the get of "t", and since the get of "t" throws we never reach the JSOP_OBJECT.  But in the JIT cases we compile the whole thing, so we compile the JSOP_OBJECT even though it's never reached in practice.

I _think_ nbp is the right person for this JSOP_OBJECT + cache stuff...

Comment 3

[Nicolas B. Pierron [:nbp]]

(In reply to Boris Zbarsky [:bz] from comment #2)
> So getSingletonsAsTemplates() ends up returning false.  
> 
> That means someone called setSingletonsAsValues() and the obvious callers
> are JSOP_OBJECT in the interpreter, the jsop_object case in IonBuilder, and
> emit_JSOP_OBJECT in baseline.
> 
> In this case, we hit emit_JSOP_OBJECT in baseline, where the object is an
> array.  WE also hit the jsop_object case in IonBuilder, of course.
> 
> I think the difference is that in the interp case the JSOP_OBJECT evaluation
> happens _after_ the get of "t", and since the get of "t" throws we never
> reach the JSOP_OBJECT.  But in the JIT cases we compile the whole thing, so
> we compile the JSOP_OBJECT even though it's never reached in practice.
> 
> I _think_ nbp is the right person for this JSOP_OBJECT + cache stuff...

I always assumed that JSOP_OBJECT was part of the prologue of any scripts and that it would have been executed before running in any compiler.

IonBuilder wants to produce a template object for the JSOP_OBJECT, I guess a work around would be to query baseline for the template object instead of creating a new one.  Then we could just make a bailout if we reach a JSOP_OBJECT without template.

Comment 4

[Hannes Verschore [:h4writer]]

Clearing, Nicolas is taking.

Comment 5

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

(In reply to Hannes Verschore [:h4writer] from comment #4)
> Clearing, Nicolas is taking.

Assigning to :nbp to keep it on his plate.

Comment 6

[Nicolas B. Pierron [:nbp]]

(In reply to Gary Kwong [:gkw] [:nth10sd] from comment #5)
> (In reply to Hannes Verschore [:h4writer] from comment #4)
> > Clearing, Nicolas is taking.
> 
> Assigning to :nbp to keep it on his plate.

Thanks, I already have a needinfo to remind me about it bug, and using the "Assigned To" field will just mess-up the way I sort my bugmail, and maybe make me loose track of it.

This bug is unfortunately not as urgent as others on which I am working on at the moment, and the test case represented in this bug does not block any upcoming work.

Comment 7

[Nicolas B. Pierron [:nbp]]

This issue is a duplicate of Bug 1108603, which now ensure that we forbid to reuse the original global because the option of the compartment do not prevent cloning singleton from the beginning.