Closed
Bug 428708
Opened 16 years ago
Closed 16 years ago
"Assertion failure: OBJ_BLOCK_COUNT(cx, obj) == 1"
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
VERIFIED
FIXED
People
(Reporter: jruderman, Assigned: igor)
References
Details
(Keywords: assertion, testcase)
Attachments
(1 file)
1.25 KB,
patch
|
brendan
:
review+
mtschrep
:
approval1.9+
|
Details | Diff | Splinter Review |
js> let ([] = <x/>.(1)) { let a; let b; } Assertion failure: OBJ_BLOCK_COUNT(cx, obj) == 1, at jsobj.c:1980 This assertion is part of code added in bug 389605. The testcase doesn't seem to cause any problems in opt.
Assignee | ||
Updated•16 years ago
|
Assignee: general → igor
Assignee | ||
Comment 1•16 years ago
|
||
The reason for the bug is that a code like { let []; let a; } generates a single let block while in the patch for bug 389605 I call EnsureNonEmptyLet for each let statement. In principle a rightful fix would be to add a call to EnsureNonEmptyLet to each js_PopStatement invocation in jsparse.c, but that would change that to fallible code touching rather few lines. So for simplicity the patch simply removes the assertion as having that synthetic empty property does not harm.
Attachment #315313 -
Flags: review?(brendan)
Comment 2•16 years ago
|
||
If there are several empty patterns in the block, all is still well? Will review later tonight. /be
Assignee | ||
Comment 3•16 years ago
|
||
(In reply to comment #2) > If there are several empty patterns in the block, all is still well? Will > review later tonight. Consider a case like: { let [] = a(); let [] = b(); } Here the first let would add the synthetic empty property to the block object. Then the second let would add nothing since the object would have at least one property at that moment. I also think that from the point of code minimality checking for [] in CheckDestructuring could be the simplest solution. It would mean that even for let([] = foo(), b = bar()) ... that synthetic property would be added. But the empty pattern is not something to optimize for and this way the checks will done only for destructuring patterns.
Comment 4•16 years ago
|
||
Comment on attachment 315313 [details] [diff] [review] v1 r=me, this is safe DEBUG-only fixage that should ride along into 1.9. /be
Attachment #315313 -
Flags: review?(brendan)
Attachment #315313 -
Flags: review+
Attachment #315313 -
Flags: approval1.9?
Updated•16 years ago
|
Attachment #315313 -
Flags: approval1.9? → approval1.9+
Assignee | ||
Comment 5•16 years ago
|
||
I checked in the patch from the comment 1 to the trunk: http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&branch=HEAD&cvsroot=%2Fcvsroot&date=explicit&mindate=1208160995&maxdate=1208161179&who=igor%25mir2.org
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Comment 6•16 years ago
|
||
/cvsroot/mozilla/js/tests/js1_7/regress/regress-428708.js,v <-- regress-428708.js initial revision: 1.1
Flags: in-testsuite+
Flags: in-litmus-
You need to log in
before you can comment on or make changes to this bug.
Description
•