1070462 - Assertion failure: !val.isMagic(), at jit/BaselineIC.cpp

Status: RESOLVED FIXED

(Core :: JavaScript Engine: JIT, defect)

Description

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

with({}) {
    let x = x += undefined
}

asserts js debug shell on m-c changeset c8e325eee9e1 with --no-threads --ion-eager at Assertion failure: !val.isMagic(), at jit/BaselineIC.cpp.

Debug configure flags:

CC="clang -Qunused-arguments" CXX="clang++ -Qunused-arguments" AR=ar sh /Users/skywalker/trees/mozilla-central/js/src/configure --target=x86_64-apple-darwin12.5.0 --enable-debug --enable-optimize --enable-nspr-build --enable-more-deterministic --with-ccache --enable-gczeal --enable-debug-symbols --disable-tests

Due to skipped revisions, the first bad revision could be any of:
changeset:   https://hg.mozilla.org/mozilla-central/rev/03242a11d044
user:        Shu-yu Guo
date:        Mon Sep 15 16:30:45 2014 -0700
summary:     Bug 1001090 - Part 2a: Compile new let opcodes in Baseline. (r=jandem)

changeset:   https://hg.mozilla.org/mozilla-central/rev/8114e77c253e
user:        Shu-yu Guo
date:        Mon Sep 15 16:30:46 2014 -0700
summary:     Bug 1001090 - Part 2b: Fix unwinding all scopes to not use pc. (r=jimb)

changeset:   https://hg.mozilla.org/mozilla-central/rev/31714af41f2c
user:        Shu-yu Guo
date:        Mon Sep 15 16:30:46 2014 -0700
summary:     Bug 1001090 - Part 3: Compile new let opcodes in Ion. (r=jandem)

Shu-yu, is bug 1001090 a possible regressor?

Comment 1

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

Attachment: stack

Comment 2

[Shu-yu Guo [:shu]]

Attachment: Fix BINDNAME/SETNAME/GETXPROP interaction with lexical temporal dead zone.

I didn't know about the GETXPROP stuff, which makes me real sad. I also
realized I wasn't doing the right thing in Baseline, so I fixed that here as
well.

Waldo, I had to change the previous behavior of BINDNAME pushing a null scope
to pushing a JS_UNINITIALIZED_LET scope, as otherwise there is no way to
distinguish between GETXPROP on an actual null value or on an uninitialized
slot.

Overall, this bug just makes me sad.

Comment 3

[Shu-yu Guo [:shu]]

Another option is to instead of pushing an JS_UNINITIALIZED_LEXICAL magical scope, push a special proxy object that throws on any get/set. I'll play with that.

Comment 4

[Shu-yu Guo [:shu]]

Attachment: Have BINDNAME push a poison scope on uninitialized lexical lookup.

This is the approach I should've taken in the beginning.

Comment 5

[Jeff Walden [:Waldo]]

Comment on attachment 8493433 [details] [diff] [review]
Have BINDNAME push a poison scope on uninitialized lexical lookup.

Review of attachment 8493433 [details] [diff] [review]:
-----------------------------------------------------------------

::: js/src/vm/ScopeObject.h
@@ +611,5 @@
> +// the scope is an uninitialized lexical, we cannot throw eagerly, as the spec
> +// demands that the error be thrown after evaluating the RHS of
> +// assignments. Instead, this sentinel scope object is pushed on the stack.
> +// Attempting to access anything on this scope throws the appropriate
> +// ReferenceError.

Gag this is horrendous.  :-)

Comment 6

[Shu-yu Guo [:shu]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/93958536e5a9

Comment 7

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/93958536e5a9