Closed Bug 1070462 Opened 6 years ago Closed 6 years ago

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

Categories

(Core :: JavaScript Engine: JIT, defect)

x86_64
macOS
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla35
Tracking Status
firefox35 --- fixed

People

(Reporter: gkw, Assigned: shu)

References

Details

(Keywords: assertion, regression, testcase, Whiteboard: [jsbugmon:update])

Attachments

(2 files, 1 obsolete file)

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?
Flags: needinfo?(shu)
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.
Attachment #8492678 - Flags: review?(jwalden+bmo)
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.
Flags: needinfo?(shu)
This is the approach I should've taken in the beginning.
Attachment #8492678 - Attachment is obsolete: true
Attachment #8492678 - Flags: review?(jwalden+bmo)
Attachment #8493433 - Flags: review?(jwalden+bmo)
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.  :-)
Attachment #8493433 - Flags: review?(jwalden+bmo) → review+
https://hg.mozilla.org/mozilla-central/rev/93958536e5a9
Assignee: nobody → shu
Status: NEW → RESOLVED
Closed: 6 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla35
You need to log in before you can comment on or make changes to this bug.