Closed
Bug 885301
Opened 11 years ago
Closed 3 years ago
crash in xpc::WrapperFactory::Rewrap
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
RESOLVED
INCOMPLETE
People
(Reporter: Honza, Assigned: jimb)
References
Details
(Keywords: crash, reproducible)
Crash Data
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
Reporter | ||
Comment 1•11 years ago
|
||
One more step: 2.5) Set the Scratchpad environment to: "Browser" Honza
Comment 2•11 years ago
|
||
Step 4 is not necessary for me.
Reporter | ||
Comment 3•11 years ago
|
||
Just to note that the problem happens on the line: global = global.unsafeDereference(); Honz
Updated•11 years ago
|
Assignee: general → nobody
Component: JavaScript Engine → XPConnect
Comment 4•11 years ago
|
||
FWIW, unsafeDereference was added in 23 by bug 837723.
Comment 5•11 years ago
|
||
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
Crash Signature: [@ xpc::WrapperFactory::Rewrap(JSContext*, JS::Handle<JSObject*>, JS::Handle<JSObject*>, JS::Handle<JSObject*>, JS::Handle<JSObject*>, unsigned int)] → [@ xpc::WrapperFactory::Rewrap(JSContext*, JS::Handle<JSObject*>, JS::Handle<JSObject*>, JS::Handle<JSObject*>, JS::Handle<JSObject*>, unsigned int)]
[@ js::MaybeGC(JSContext*) ]
Updated•11 years ago
|
Flags: needinfo?(jimb)
Comment 6•11 years ago
|
||
Looks like the debugger API is trying to wrap a null object.
Assignee: nobody → general
Component: XPConnect → JavaScript Engine
Assignee | ||
Comment 7•11 years ago
|
||
Hmm. A Debugger.Object's referent should never be null. (Tried to reproduce in the shell and failed; trying browser...)
Flags: needinfo?(jimb)
Assignee | ||
Comment 8•11 years ago
|
||
... and I can reproduce it there. Waiting for a fresh build with debugging enabled.
Assignee | ||
Updated•11 years ago
|
Assignee: general → jimb
Assignee | ||
Comment 9•11 years ago
|
||
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?
Assignee | ||
Comment 10•11 years ago
|
||
Oh, wait, 885388 isn't the right bug... I meant bug 897322: "Redesign JS_NewGlobalObject API to sanely handle onNewGlobalObject debugger hooks"
Comment 11•11 years ago
|
||
Oh yeah, this stack trace is coming out of JS_NewGlobalObject. Yeah, that's almost certainly the problem.
Depends on: 897322
Updated•9 years ago
|
Crash Signature: [@ xpc::WrapperFactory::Rewrap(JSContext*, JS::Handle<JSObject*>, JS::Handle<JSObject*>, JS::Handle<JSObject*>, JS::Handle<JSObject*>, unsigned int)]
[@ js::MaybeGC(JSContext*) ] → [@ xpc::WrapperFactory::Rewrap(JSContext*, JS::Handle<JSObject*>, JS::Handle<JSObject*>, JS::Handle<JSObject*>, JS::Handle<JSObject*>, unsigned int)]
[@ js::MaybeGC(JSContext*) ]
[@ xpc::WrapperFactory::Rewrap]
[@ js::MaybeGC ]
Comment 12•3 years ago
|
||
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.
Flags: needinfo?(jimb)
Comment 13•3 years ago
|
||
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.
Status: NEW → RESOLVED
Closed: 3 years ago
Flags: needinfo?(jimb)
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•