Closed Bug 1103048 Opened 10 years ago Closed 9 years ago

Assertion failure: data.s.payload.why == why, at dist/include/js/Value.h

Categories

(Core :: JavaScript Engine: JIT, defect)

x86_64
macOS
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla36
Tracking Status
firefox36 --- affected

People

(Reporter: gkw, Assigned: shu)

References

Details

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

Attachments

(2 files)

g = this;
(function(y) {
    "use strict"
    for (let j = 0; j < 1; j++) {
        g
        z => {
            y
        }
    }
})()

asserts js debug shell on m-c changeset 7d17b594834f with --ion-eager --no-threads at Assertion failure: data.s.payload.why == why, at dist/include/js/Value.h.

Debug configure options:

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-optimize --enable-nspr-build --enable-more-deterministic --with-ccache --enable-gczeal --enable-debug-symbols --disable-tests
Flags: needinfo?
Attached file stack
(lldb) bt 5
* thread #1: tid = 0x27f6e3, 0x000000010052f06d js-dbg-opt-64-dm-nsprBuild-darwin-7d17b594834f`UpdatePropertyType(cx=<unavailable>, types=<unavailable>, obj=<unavailable>, shape=<unavailable>, indexed=<unavailable>) + 1501 at jsinfer.cpp:2947, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
  * frame #0: 0x000000010052f06d js-dbg-opt-64-dm-nsprBuild-darwin-7d17b594834f`UpdatePropertyType(cx=<unavailable>, types=<unavailable>, obj=<unavailable>, shape=<unavailable>, indexed=<unavailable>) + 1501 at jsinfer.cpp:2947
    frame #1: 0x000000010052e832 js-dbg-opt-64-dm-nsprBuild-darwin-7d17b594834f`js::types::TypeObject::updateNewPropertyTypes(this=<unavailable>, cx=0x0000000101b14ec0, types=0x000000010482f910, id=<unavailable>) + 1010 at jsinfer.cpp:3029
    frame #2: 0x00000001005a5a85 js-dbg-opt-64-dm-nsprBuild-darwin-7d17b594834f`js::types::TypeObject::getProperty(this=0x0000000101f5b8c8, cx=0x0000000101b14ec0, id=<unavailable>) + 373 at jsinferinlines.h:1256
    frame #3: 0x00000001005a54e2 js-dbg-opt-64-dm-nsprBuild-darwin-7d17b594834f`js::types::EnsureTrackPropertyTypes(cx=0x0000000101b14ec0, obj=0x0000000101f74c40, id=<unavailable>) + 274 at jsinferinlines.h:429
    frame #4: 0x000000010031aa13 js-dbg-opt-64-dm-nsprBuild-darwin-7d17b594834f`js::jit::TrackAllProperties(cx=0x0000000101b14ec0, obj=0x0000000101f74c40) + 99 at Ion.cpp:1852
(lldb)
Whiteboard: [jsbugmon:update,bisect] → [jsbugmon:update]
JSBugMon: Bisection requested, result:
autoBisect shows this is probably related to the following changeset:

The first bad revision is:
changeset:   https://hg.mozilla.org/mozilla-central/rev/748ffeff132c
user:        Shu-yu Guo
date:        Wed Oct 15 18:06:49 2014 -0700
summary:     Bug 1076026 - Don't consider uninitialized lexicals when initializing a singleton object property type. (r=bhackett)

This iteration took 366.127 seconds to run.
Assignee: nobody → shu
Comment on attachment 8527073 [details] [diff] [review]
Don't track the type of optimized out values in CallObjects.

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

This seems really weird.  How is an optimized out value getting into a call object?  That seems like it should be impossible.
(In reply to Brian Hackett (:bhackett) from comment #4)
> Comment on attachment 8527073 [details] [diff] [review]
> Don't track the type of optimized out values in CallObjects.
> 
> Review of attachment 8527073 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> This seems really weird.  How is an optimized out value getting into a call
> object?  That seems like it should be impossible.

I agree it's really weird. Looking at the fuzz test:

g = this;
(function(y) {
    "use strict"
    for (let j = 0; j < 1; j++) {
        g
        z => {
            y
        }
    }
})()

What's aliased is 'y', and it's being optimized out because it has no uses. I haven't dug too deep, but I guess it's because the function that closes over y is also dead. If I return that closure or call it or something, there's no crash.
Comment on attachment 8527073 [details] [diff] [review]
Don't track the type of optimized out values in CallObjects.

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

OK, fair enough.
Attachment #8527073 - Flags: review?(bhackett1024) → review+
(In reply to Brian Hackett (:bhackett) from comment #6)
> Comment on attachment 8527073 [details] [diff] [review]
> Don't track the type of optimized out values in CallObjects.
> 
> Review of attachment 8527073 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> OK, fair enough.

I forgot to mention that the argument can only be optimized out because of the "use strict", otherwise it's always visible via Function.arguments.
https://hg.mozilla.org/mozilla-central/rev/e2469b3b6aa8
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla37
Target Milestone: mozilla37 → mozilla36
You need to log in before you can comment on or make changes to this bug.