885301 - crash in xpc::WrapperFactory::Rewrap

Status: RESOLVED INCOMPLETE

(Core :: JavaScript Engine, defect)

Description

[Jan Honza Odvarko [:Honza] (always need-info? me)]

This bug was filed from the Socorro interface and is 
report bp-5d81cad1-1a7d-4d85-981b-ca1122130620 .
============================================================= 

STR:

1) Load this page:
http://www.softwareishard.com/temp/bugzilla/issue6523.html

2) Open Scratchpad and put in the following code:

var win = gBrowser.mCurrentBrowser._contentWindow.window;

var jsDebugger = {};
Cu.import("resource://gre/modules/jsdebugger.jsm", jsDebugger);

var global = Cu.getGlobalForObject({});
jsDebugger.addDebuggerToGlobal(global);

var dbg = new global.Debugger();

dbg.addDebuggee(win);

dbg.onNewGlobalObject = function(global)
{
    global = global.unsafeDereference();
    win.console.log('onNewGlobalObject', global);
}

3) Eval the code in Scratchpad

4) Click the button on the web page -> CRASH

Honza

Comment 1

[Jan Honza Odvarko [:Honza] (always need-info? me)]

One more step:
2.5) Set the Scratchpad environment to: "Browser"

Honza

Comment 2

[Scoobidiver (away)]

Step 4 is not necessary for me.

Comment 3

[Jan Honza Odvarko [:Honza] (always need-info? me)]

Just to note that the problem happens on the line:

global = global.unsafeDereference();

Honz

Comment 4

[Andrew McCreight [:mccr8]]

FWIW, unsafeDereference was added in 23 by bug 837723.

Comment 5

[Scoobidiver (away)]

In 21.0 with step 4: bp-06098fac-f463-4359-b8be-ff3282130620
In 22.0b6 with step 4: bp-5c204c36-938b-41e5-ae0f-aa1c42130620
In 23.0a2: bp-f706776d-f4b5-4730-bb3b-fbb692130620

Comment 6

[Bobby Holley (:bholley)]

Looks like the debugger API is trying to wrap a null object.

Comment 7

[Jim Blandy :jimb]

Hmm. A Debugger.Object's referent should never be null.

(Tried to reproduce in the shell and failed; trying browser...)

Comment 8

[Jim Blandy :jimb]

... and I can reproduce it there. Waiting for a fresh build with debugging enabled.

Comment 9

[Jim Blandy :jimb]

I wonder if this isn't the same as bug 885388.

The Debugger.Object passed to the onNewGlobalObject hook has the correct inner window object as its referent. Debugger.Object.prototype.unsafeDereference retrieves that, and then applies JSCompartment::wrap to it to make a CCW for it in the caller's compartment. We then have:

JSCompartment::wrap
-> xpc::WrapperFactory::PrepareForWrapping (via cx->runtime()->preWrapObjectCallback)
-> xpc:JS_ObjectToOuterObject
-> GetOuterObject
-> XPC_WN_OuterObject (via obj->getClass()->ext.outerObject)
-> XPCWrappedNative::Get
-> js::GetObjectPrivate

which returns NULL. Could the problem simply be that the inner window object's private pointer hasn't been initialized yet, because the onNewGlobalObject hook is firing too early --- which bug 885388 fixes?

Comment 10

[Jim Blandy :jimb]

Oh, wait, 885388 isn't the right bug... I meant bug 897322: "Redesign JS_NewGlobalObject API to sanely handle onNewGlobalObject debugger hooks"

Comment 11

[Bobby Holley (:bholley)]

Oh yeah, this stack trace is coming out of JS_NewGlobalObject. Yeah, that's almost certainly the problem.

Comment 12

[Daniel Bodea [:danibodea]]

According to the crash signature reports, this is a crash found 90% on Fenix. In the latest reports, there are a few crashes on Release Fx84 and Fx85.
Furthermore, the steps to reproduce in comment 0 are no longer valid because the web-page in step one is no longer existent.

@Jim: Do you think other steps to reproduce could be found or deduced from the old ones?
Please NI me if I can help on the testing side. Thanks.

Comment 13

[Andrew McCreight [:mccr8]]

I think we can just close this old bug. If the new crash is an issue, a new bug would be better, but the volume looks very low.