346364 - abort() when closing windows (sb-loader.js related?) Assertion failure: !OBJ_GET_PROTO(cx, ctor), at c:/builds/bonecho/mozilla/js/src/jsapi.c:2250

Status: RESOLVED FIXED

(Core :: XPConnect, defect)

Description

[(not reading, please use [e-mail] instead)]

abort() when closing windows (sb-loader.js related?) Assertion failure: !OBJ_GET_PROTO(cx, ctor), at c:/builds/bonecho/mozilla/js/src/jsapi.c:2250

I hit this when closing windows really fast (I think.)

note, I'm running a 1.8.1 branch debug build from 7/25 *before* blake checked in his fix for bug #343417

I'm updating and rebuilding.

blake thinks his fix for bug #343417 will address this.


here was my stack:

 	ntdll.dll!7c901230() 	
 	[Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]	
 	js3250.dll!JS_Assert(const char * s=0x100fc750, const char * file=0x100fc724, int ln=0x000008ca)  Line 62	C
 	js3250.dll!JS_InitClass(JSContext * cx=0x01d88ac8, JSObject * obj=0x0370cfa0, JSObject * parent_proto=0x0370cf50, JSClass * clasp=0x1010c798, int (JSContext *, JSObject *, unsigned int, long *, long *)* constructor=0x100484b0, unsigned int nargs=0x00000001, JSPropertySpec * ps=0x1010c198, JSFunctionSpec * fs=0x1010d0e0, JSPropertySpec * static_ps=0x00000000, JSFunctionSpec * static_fs=0x00000000)  Line 2250 + 0x10a bytes	C
 	js3250.dll!js_InitFunctionClass(JSContext * cx=0x01d88ac8, JSObject * obj=0x0370cfa0)  Line 2024 + 0x29 bytes	C
 	js3250.dll!js_InitFunctionAndObjectClasses(JSContext * cx=0x01d88ac8, JSObject * obj=0x0370cfa0)  Line 1165 + 0xd bytes	C
 	js3250.dll!JS_ResolveStandardClass(JSContext * cx=0x01d88ac8, JSObject * obj=0x0370cfa0, long id=0x00c7ec54, int * resolved=0x0012e910)  Line 1469 + 0xf bytes	C
>	gklayout.dll!nsWindowSH::NewResolve(nsIXPConnectWrappedNative * wrapper=0x0477c670, JSContext * cx=0x01d88ac8, JSObject * obj=0x0370cfa0, long id=0x00c7ec54, unsigned int flags=0x00000000, JSObject * * objp=0x0012ea24, int * _retval=0x0012e9a0)  Line 5915 + 0x2a bytes	C++
 	xpc3250.dll!XPC_WN_Helper_NewResolve(JSContext * cx=0x01d88ac8, JSObject * obj=0x0370cfa0, long idval=0x00c7ec54, unsigned int flags=0x00000000, JSObject * * objp=0x0012eaa4)  Line 1063 + 0x47 bytes	C++
 	js3250.dll!js_LookupPropertyWithFlags(JSContext * cx=0x01d88ac8, JSObject * obj=0x0370cfa0, long id=0x00c81448, unsigned int flags=0x00000000, JSObject * * objp=0x0012eb48, JSProperty * * propp=0x0012eb38)  Line 3021 + 0x4c bytes	C
 	js3250.dll!js_LookupProperty(JSContext * cx=0x01d88ac8, JSObject * obj=0x0370cfa0, long id=0x00c81448, JSObject * * objp=0x0012eb48, JSProperty * * propp=0x0012eb38)  Line 2926 + 0x1b bytes	C
 	js3250.dll!js_FindProperty(JSContext * cx=0x01d88ac8, long id=0x00c81448, JSObject * * objp=0x0012f474, JSObject * * pobjp=0x0012f508, JSProperty * * propp=0x0012f460)  Line 3135 + 0x21 bytes	C
 	js3250.dll!js_Interpret(JSContext * cx=0x01d88ac8, unsigned char * pc=0x02eba600, long * result=0x0012f66c)  Line 4169 + 0x1f bytes	C
 	js3250.dll!js_Invoke(JSContext * cx=0x01d88ac8, unsigned int argc=0x00000002, unsigned int flags=0x00000002)  Line 1368 + 0x13 bytes	C
 	xpc3250.dll!nsXPCWrappedJSClass::CallMethod(nsXPCWrappedJS * wrapper=0x04816600, unsigned short methodIndex=0x0003, const nsXPTMethodInfo * info=0x02ebe4f8, nsXPTCMiniVariant * nativeParams=0x0012f9dc)  Line 1415 + 0x14 bytes	C++
 	xpc3250.dll!nsXPCWrappedJS::CallMethod(unsigned short methodIndex=0x0003, const nsXPTMethodInfo * info=0x02ebe4f8, nsXPTCMiniVariant * params=0x0012f9dc)  Line 468	C++
 	xpcom_core.dll!PrepareAndDispatch(nsXPTCStubBase * self=0x04816600, unsigned int methodIndex=0x00000003, unsigned int * args=0x0012faa4, unsigned int * stackBytesToPop=0x0012fa94)  Line 117 + 0x1e bytes	C++
 	xpcom_core.dll!SharedStub()  Line 147	C++
 	brwsrcmp.dll!nsDocNavStartProgressListener::Observe(nsISupports * subject=0x049690e0, const char * topic=0x0012fab4, const wchar_t * data=0x04816600)  Line 321	C++
 	brwsrcmp.dll!nsDocNavStartProgressListener::Observe(nsISupports * subject=0x0533b810, const char * topic=0x0036cf1c, const wchar_t * data=0x00000000)  Line 321	C++
 	xpcom_core.dll!nsTimerImpl::Fire()  Line 407	C++
 	xpcom_core.dll!nsTimerManager::FireNextIdleTimer()  Line 628	C++
 	gkwidget.dll!nsAppShell::Run()  Line 142	C++
 	tkitcmps.dll!nsAppStartup::Run()  Line 151 + 0x1c bytes	C++
 	firefox.exe!XRE_main(int argc=0x00000001, char * * argv=0x00a27db0, const nsXREAppData * aAppData=0x004247c0)  Line 2433 + 0x25 bytes	C++
 	firefox.exe!main(int argc=0x00000001, char * * argv=0x00a27db0)  Line 61 + 0x12 bytes	C++
 	firefox.exe!__tmainCRTStartup()  Line 586 + 0x19 bytes	C
 	firefox.exe!mainCRTStartup()  Line 403	C
 	kernel32.dll!7c816d4f() 	
 	kernel32.dll!7c8399f3() 	
 	xpcom_core.dll!nsBinaryInputStream::Release()  Line 293 + 0xd2 bytes	C++
 	xpcom_core.dll!nsBinaryInputStream::Release()  Line 293 + 0xd2 bytes	C++
 	70632e6d()	

here was what I saw on the console:

###!!! ASSERTION: XPConnect is being called on a scope without a 'Components' pr
operty!

This is pretty much always bad. It usually means that native code is
making a callback to an interface implemented in JavaScript, but the
document where the JS object was created has already been cleared and the
global properties of that document's window are *gone*. Generally this
indicates a problem that should be addressed in the design and use of the
callback code.
: 'Error', file c:/builds/bonecho/mozilla/js/src/xpconnect/src/xpcwrappednatives
cope.cpp, line 564
Assertion failure: !OBJ_GET_PROTO(cx, ctor), at c:/builds/bonecho/mozilla/js/src
/jsapi.c:2250
WARNING: Dropping timer event because thread is dead, file c:/builds/bonecho/moz
illa/xpcom/threads/nsTimerImpl.cpp, line 510

blake determined that that the js in question was:

http://lxr.mozilla.org/mozilla1.8/source/browser/components/safebrowsing/content/sb-loader.js#54

 51   progressListenerCallback: {
 52     requests: [],
 53     onDocNavStart: function(request, url) {
 54       this.requests.push({
 55         'request': request,
 56         'url': url
 57       });
 58     }
 59   },

Comment 1

[(not reading, please use [e-mail] instead)]

mats, could this be what you were seeing in bug #344857 comment #5?

Comment 2

[Blake Kaplan (:mrbkap) (inactive)]

I believe this bug was actually fixed by the patch in bug 343417. Here's what I think happened:
 - Seth closed the window (or tab), which caused nsGlobalWindow::SetDocShell to call JS_ClearScope on the inner window. Before the patch for bug 343417, this would clear all of the properties on the window itself, but not the class object cache.
 - The safebrowsing stuff, running off of a timer, causes us to look up "Object" in the scope of the window. Since the scope was cleared on the window, this causes us to do a resolve, which lands us in JS_ResolveStandardClass.
 - Since we're resolving Object, we end up in js_InitFunctionAndObjectClasses, which ends up calling JS_InitClass for Function; however, when we create the prototype function object, we call js_GetClassObject, which finds the old cached class object, causing us to assert.

With the fix for bug 343417, we also clear the cached Function prototype object, so when we re-resolve Object, there's no cache Function prototype object, and we shouldn't assert.