496251 - Crash [@ JITted code] or "Assertion failure: uint32(unboxed) <= 2, at ../jsbuiltins.cpp" with type-unstable loop and upvar referring to let

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Jesse Ruderman]

let (z = {}) {
    for (var i = 0; i < 4; ++i) {
        for each (var e in [{}, 1, {}]) {
            +(function () z)();
        }
    }
}

Crash [@ JITted code]

Comment 1

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

autoBisect shows this is probably related to bug 494269 :

The first bad revision is:
changeset:   28896:a16ed38ff63a
user:        David Mandelin
date:        Wed Jun 03 11:19:20 2009 -0700
summary:     Bug 494269: trace JSOP_LAMBDA_FC, r=brendan,gal

Comment 2

[Andreas Gal :gal]

No need to block. Underlying patch is not on branch.

Comment 3

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

(In reply to comment #2)
> No need to block. Underlying patch is not on branch.

OK, I should have nominated blocking-1.9.2? then.

Comment 4

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

for (;;) {
    for each(let b in [(void 0), {}]) {
        print('' + ((function() {
            for (var e in [''
            for (b in [''])]) {
                print('' + b)
            }
        })()))
    }
}

asserts at Assertion failure: uint32(unboxed) <= 2, at ../jsbuiltins.cpp:388 in debug TM js shell with -j enabled.

Comment 5

[Jesse Ruderman]

This prints something other than zeroes.  Same bug?

    var o = [];
    for (var a = 0; a < 9; ++a) {
        var unused = 0;
        let (zero = 0) {
            for (var ee = 0; ee < 1; ++ee) {
                o.push((function () zero)());
            }
        }
    }
    print(o.join(" "));

Comment 6

[David Mandelin [:dmandelin]]

The test cases in comments 0 and 5 seem to be fixed by a6f9df8c33a9 from bug 496270. But the behavior in comment 4 still stands. So I'll consider that to be what this bug is about.

Comment 7

[David Mandelin [:dmandelin]]

Attachment: Patch

Patch for the test case in comment 4 (the only outstanding one). 

The problem was that for the case where the upvar was defined on the frame active at start of trace, I was using the entry type map rather than the type map at the time of the call. Types can change between those times. Also, by inspection you can see that the new special case code is really the same as the code to get the typemap inside the general case loop.

Comment 8

[David Mandelin [:dmandelin]]

Pushed to TM as 1cfe7ecbb88f.

Comment 10

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

(In reply to comment #9)
> *** Bug 496867 has been marked as a duplicate of this bug. ***

Nominating blocking1.9.1? to get the patch into 1.9.1 branch, since the duped bug occurred on the branch and the latest patch here fixes it.

Comment 12

[Robert Sayre]

http://hg.mozilla.org/mozilla-central/rev/1cfe7ecbb88f

Comment 13

[Robert Sayre]

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/a58ab4be5304

Comment 14

[Mike Beltzner [:beltzner, not reading bugmail]]

Mass change: adding fixed1.9.2 keyword

(This bug was identified as a mozilla1.9.2 blocker which was fixed before the mozilla-1.9.2 repository was branched (August 13th, 2009) as per this query: http://is.gd/2ydcb - if this bug is not actually fixed on mozilla1.9.2, please remove the keyword. Apologies for the bugspam)

Comment 15

[Christian Holler (:decoder)]

Automatically extracted testcase for this bug was committed:

https://hg.mozilla.org/mozilla-central/rev/efaf8960a929