509557 - Assertion failure: JSVAL_IS_INT(v) in XPC_NW_AddProperty

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[David Anderson [:dvander] - inactive, e-mail if emergency]

Attachment: backtrace

Occurs on startup of running mochitests.  Full bt in attachment.

Assertion failure: JSVAL_IS_INT(v), at /Users/mozilla/dvander/tracemonkey/js/src/jsapi.h:243

(gdb) up
#1  0x047452ec in JSVAL_TO_INT (v=22) at jsapi.h:243
243	    JS_ASSERT(JSVAL_IS_INT(v));
(gdb) up
#2  0x047477bb in XPC_NW_AddProperty (cx=0x1071c00, obj=0x72a080, id=7520644, vp=0xbfffe61c) at /Users/mozilla/dvander/tracemonkey/js/src/xpconnect/src/XPCNativeWrapper.cpp:380
380	  if (!HAS_FLAGS(flags, FLAG_RESOLVING)) {

Comment 1

[Boris Zbarsky [:bzbarsky]]

I pushed http://hg.mozilla.org/tracemonkey/rev/b366334f5c77 to make it semi-possible to actually use a debug Firefox build from t-m.

That should be backed out when we fix this for real.

As I recall from the debugging mrbkap did last night, the problem is that we're doing a property add on the prototype of XPCNativeWrapper.

Options include:

1)  Keep the hackaround I just pushed.
2)  Detect that we're the prototype and bail out early in cases when we want
    the flags.
3)  Set the flags on the prototype (?)

Comment 2

[Robert Sayre]

who should this  assigned to? mrbkap?

Comment 3

[Blake Kaplan (:mrbkap) (inactive)]

Attachment: Patchset to fix this

In order to detect that we're initializing the prototype, we have to avoid initializing XPCNativeWrapper twice.

Comment 4

[Blake Kaplan (:mrbkap) (inactive)]

Attachment: Patchset to fix this

We need to null-check obj in the XPCNativeWrapper constructor.

Comment 6

[Blake Kaplan (:mrbkap) (inactive)]

Attachment: Patchset to fix this

Comment 7

[Boris Zbarsky [:bzbarsky]]

Why is the nsIXPConnect change needed here?

Comment 8

[Blake Kaplan (:mrbkap) (inactive)]

(In reply to comment #7)
> Why is the nsIXPConnect change needed here?
 
The call to InitClasses re-initializes XPCNativeWrapper. Because by this point, we've already initialized XPCNativeWrapper on the inner window, we end up re-initializing XPCNativeWrapper.prototype. This wouldn't be a problem, but we have to detect that we're dealing with the prototype in the constructor *somehow* (otherwise we'd throw). We do so by checking if the __proto__ of the passed-in object is an XPCNativeWrapper. Without the XPConnect change, we'd actually find a prototype (on the inner window) for the new prototype and fail.

Comment 9

[Robert Sayre]

jst?

Comment 10

[Blake Kaplan (:mrbkap) (inactive)]

http://hg.mozilla.org/mozilla-central/rev/848d6079e3ea
http://hg.mozilla.org/mozilla-central/rev/19413240b354
http://hg.mozilla.org/mozilla-central/rev/7653df541fbe
http://hg.mozilla.org/mozilla-central/rev/5cd4cc4d801e