822171 - "Assertion failure: !global->nativeLookupNoAllocation(id),"

Status: RESOLVED DUPLICATE of bug 824217

(Core :: JavaScript Engine, defect)

Description

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

Attachment: stack

x = evalcx('lazy')
x.Int16Array = Int16Array
uneval(x)

asserts js debug shell on m-c changeset c8a1314aa449 without any CLI arguments at Assertion failure: !global->nativeLookupNoAllocation(id),

See bug 799898, which has a testcase that seems a little different.

Comment 1

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

autoBisect shows this is probably related to the following changeset:

The first bad revision is:
changeset:   107534:adab1fdcfe0a
user:        Luke Wagner
date:        Tue Sep 04 14:31:04 2012 -0700
summary:     Bug 786801 - js_InferFlags should not stop at compartment boundaries (r=bhackett)

Luke, is this a possible regressor?

Comment 2

[Christian Holler (:decoder)]

See also bug 799898, likely a dup of that. However, if it's the same issue, the test confirms that the issue isn't E4X only.

Comment 3

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

Yes, that was mentioned in comment 0, adding to "See Also" for good measure.

Comment 4

[Luke Wagner [:luke]]

I think this is just a bug in sandbox_resolve (and thus shell-only) that was exposed by bug 786801 fixing brokenness:

In comment 0 we overwrite Int16Array but fail to js_InitTypedArrayClasses which means that we add a regular property "Int16Array".  Thus, when we *do* js_InitTypedArrayClasses later, we hit the assert that we haven't already defined the property we are about to initialize.

Why do we fail to js_InitTypedArrayClasses?  Because sandbox_resolve doesn't JS_ResolveStandardClases if JSRESOLVE_ASSIGNING which is set for the cross-compartment JSOP_SETPROP in the first line of comment 0 (which, before bug 786801 would have incorrectly been !JSRESOLVE_ASSIGNING).

Waldo: should we just remove the JSRESOLVE_ASSIGNING test in sandbox_resolve?

Comment 5

[Jeff Walden [:Waldo]]

Yes.  We need to remove JSRESOLVE_ASSIGNING anyway to get rid of resolve flags.  (And even current uses of it are broken in any case, see bug 547140.)

Comment 6

[Christian Holler (:decoder)]

JSBugMon: The testcase found in this bug no longer reproduces (tried revision 4e18ac9b51e2).

Comment 7

[Christian Holler (:decoder)]

JSBugMon: The testcase found in this bug no longer reproduces (tried revision 4e18ac9b51e2).
JSBugMon: Fix Bisection requested, result:
autoBisect shows this is probably related to the following changeset:

The first good revision is:
changeset:   117329:0ce29ce2ea7c
user:        Jeff Walden
date:        Wed Dec 19 19:32:34 2012 -0500
summary:     Bug 824217 - Remove some easy-to-remove tests of JSRESOLVE_ASSIGNING.  r=bz

This iteration took 0.379 seconds to run.