700799 - [ObjShrink] "Assertion failure: withobj->getClass() == &WithClass,"

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

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

Attachment: stack

for (let x in [<y/>.(let(x) function() {})]) {}

asserts js debug shell on JM changeset 1210706b4576 with patch v1 from bug 697279 without any CLI flags at Assertion failure: withobj->getClass() == &WithClass,

autoBisect shows this is probably related to the following changeset:

The first bad revision is:
changeset:   78142:f852758f39d1
user:        Brian Hackett
date:        Thu Oct 13 20:21:36 2011 -0700
summary:     Move JSObject::parent to BaseShape, bug 638316.

Comment 1

[Brian Hackett [Laid off!]]

Attachment: patch

Semantic difference vs. trunk that seems to have been exposed by breakage elsewhere in the VM.  When parsing the inner let block the parser sets the static block chain of the inner let to the outer one, and later resets it to NULL (!).  The JM branch changed this (wrong) behavior to ignore the second set and keep the static block chain of the inner let pointing to the outer let.  Later on when interpreting, the XML filter creates a With object that somehow gets an incorrect static block chain and doesn't force construction of the block for the outer let, so that the with object has the wrong parent.  *Still* later, when constructing the block object for the inner let GetScopeChainFull manages to find the outer let, parents the inner one to the outer one and skips the with, then we die when ending the filter because the frame's scope chain is wrong.

I don't really have any clue how any of this code works, so this patch just restores the same behavior as trunk and constructs an incorrect static block chain for the let statements.  But this should be fixed for real (it is probably a dupe of something else, that let block in the for loop looks suspicious).

https://hg.mozilla.org/projects/jaegermonkey/rev/8bea0b58c9ff

Comment 2

[Brian Hackett [Laid off!]]

Attachment: patch

Oops, wrong file.

Comment 3

[Luke Wagner [:luke]]

Comment on attachment 573037 [details] [diff] [review]
patch

This fix almost dovetails exactly with bug 638316 comment 22 paragraph 1 if you use ObjectOrNullValue instead of UndefinedValue.

Comment 4

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

(In reply to Luke Wagner [:luke] from comment #3)
> Comment on attachment 573037 [details] [diff] [review] [diff] [details] [review]
> patch
> 
> This fix almost dovetails exactly with bug 638316 comment 22 paragraph 1 if
> you use ObjectOrNullValue instead of UndefinedValue.

Is this bug still valid for m-c? (seems to be fixed on JM per comment 1) If so, probably the summary should be changed, or a new bug filed. I'm not sure I see the assert on m-c.

Comment 5

[Christian Holler (:decoder)]

A testcase for this bug was automatically identified at js/src/jit-test/tests/e4x/bug700799.js.