Closed Bug 428708 Opened 16 years ago Closed 16 years ago

"Assertion failure: OBJ_BLOCK_COUNT(cx, obj) == 1"

Categories

(Core :: JavaScript Engine, defect)

x86
macOS
defect
Not set
critical

Tracking

()

VERIFIED FIXED

People

(Reporter: jruderman, Assigned: igor)

References

Details

(Keywords: assertion, testcase)

Attachments

(1 file)

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: general → igor
Attached patch v1Splinter Review
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)
If there are several empty patterns in the block, all is still well? Will review later tonight.

/be
(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 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?
Attachment #315313 - Flags: approval1.9? → approval1.9+
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
/cvsroot/mozilla/js/tests/js1_7/regress/regress-428708.js,v  <--  regress-428708.js
initial revision: 1.1
Flags: in-testsuite+
Flags: in-litmus-
v 1.9.0
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: