Closed Bug 496251 Opened 15 years ago Closed 15 years ago

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

Categories

(Core :: JavaScript Engine, defect)

defect
Not set
critical

Tracking

()

RESOLVED FIXED
Tracking Status
status1.9.2 --- beta1-fixed

People

(Reporter: jruderman, Assigned: dmandelin)

References

Details

(5 keywords)

Crash Data

Attachments

(1 file)

let (z = {}) { for (var i = 0; i < 4; ++i) { for each (var e in [{}, 1, {}]) { +(function () z)(); } } } Crash [@ JITted code]
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
Blocks: 494269
Flags: blocking1.9.1?
Keywords: regression
No need to block. Underlying patch is not on branch.
Flags: blocking1.9.1?
(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.
Flags: blocking1.9.2?
Assignee: general → dmandelin
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.
Keywords: assertion
OS: Mac OS X → All
Hardware: x86 → All
Summary: Crash [@ JITted code] with type-unstable loop and upvar referring to let → Crash [@ JITted code] or "Assertion failure: uint32(unboxed) <= 2, at ../jsbuiltins.cpp" with type-unstable loop and upvar referring to let
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(" "));
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.
Attached patch Patch (deleted) — Splinter Review
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.
Attachment #381888 - Flags: review?(gal)
Attachment #381888 - Flags: review?(gal) → review+
Pushed to TM as 1cfe7ecbb88f.
(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.
Flags: blocking1.9.1?
Flags: blocking1.9.2?
Flags: blocking1.9.2+
Flags: blocking1.9.1?
Flags: blocking1.9.1-
Flags: blocking1.9.1- → blocking1.9.1+
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Blocks: 496784
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)
Keywords: fixed1.9.2
Crash Signature: [@ JITted code]
Automatically extracted testcase for this bug was committed: https://hg.mozilla.org/mozilla-central/rev/efaf8960a929
Flags: in-testsuite+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: