As a security precaution, we have turned on the setting "Require API key authentication for API requests" for everyone. If this has broken something, please contact
Last Comment Bug 700799 - [ObjShrink] "Assertion failure: withobj->getClass() == &WithClass,"
: [ObjShrink] "Assertion failure: withobj->getClass() == &WithClass,"
: assertion, regression, testcase
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: Trunk
: x86 Mac OS X
: -- critical (vote)
: ---
Assigned To: general
: Jason Orendorff [:jorendorff]
Depends on:
Blocks: jsfunfuzz 638316
  Show dependency treegraph
Reported: 2011-11-08 14:00 PST by Gary Kwong [:gkw] [:nth10sd]
Modified: 2013-01-14 08:17 PST (History)
3 users (show)
choller: in‑testsuite+
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

stack (3.06 KB, text/plain)
2011-11-08 14:00 PST, Gary Kwong [:gkw] [:nth10sd]
no flags Details
patch (45.72 KB, patch)
2011-11-08 16:20 PST, Brian Hackett (:bhackett)
no flags Details | Diff | Splinter Review
patch (3.65 KB, patch)
2011-11-08 16:21 PST, Brian Hackett (:bhackett)
luke: review+
Details | Diff | Splinter Review

Description User image Gary Kwong [:gkw] [:nth10sd] 2011-11-08 14:00:29 PST
Created attachment 572997 [details]

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 User image Brian Hackett (:bhackett) 2011-11-08 16:20:04 PST
Created attachment 573036 [details] [diff] [review]

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).
Comment 2 User image Brian Hackett (:bhackett) 2011-11-08 16:21:18 PST
Created attachment 573037 [details] [diff] [review]

Oops, wrong file.
Comment 3 User image Luke Wagner [:luke] 2011-11-08 16:24:39 PST
Comment on attachment 573037 [details] [diff] [review]

This fix almost dovetails exactly with bug 638316 comment 22 paragraph 1 if you use ObjectOrNullValue instead of UndefinedValue.
Comment 4 User image Gary Kwong [:gkw] [:nth10sd] 2011-11-23 12:34:39 PST
(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 User image Christian Holler (:decoder) 2013-01-14 08:17:26 PST
A testcase for this bug was automatically identified at js/src/jit-test/tests/e4x/bug700799.js.

Note You need to log in before you can comment on or make changes to this bug.