Closed Bug 509557 Opened 10 years ago Closed 10 years ago

Assertion failure: JSVAL_IS_INT(v) in XPC_NW_AddProperty

Categories

(Core :: JavaScript Engine, defect)

x86
macOS
defect
Not set

Tracking

()

RESOLVED FIXED

People

(Reporter: dvander, Assigned: mrbkap)

Details

Attachments

(2 files, 1 obsolete file)

Attached file 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)) {
Attachment #393609 - Attachment mime type: application/octet-stream → text/plain
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 (?)
who should this  assigned to? mrbkap?
Assignee: general → mrbkap
Attached patch Patchset to fix this (obsolete) — Splinter Review
In order to detect that we're initializing the prototype, we have to avoid initializing XPCNativeWrapper twice.
Attachment #395008 - Flags: superreview?(bzbarsky)
Attachment #395008 - Flags: review?(jst)
Attached patch Patchset to fix this (obsolete) — Splinter Review
We need to null-check obj in the XPCNativeWrapper constructor.
Attachment #395008 - Attachment is obsolete: true
Attachment #395008 - Flags: superreview?(bzbarsky)
Attachment #395008 - Flags: review?(jst)
Attachment #395479 - Flags: superreview?(bzbarsky)
Attachment #395479 - Flags: review?(jst)
Why is the nsIXPConnect change needed here?
(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.
Attachment #395479 - Flags: superreview?(bzbarsky) → superreview+
jst?
Attachment #395479 - Flags: review?(jst) → review+
You need to log in before you can comment on or make changes to this bug.