337648 - Thread unsafe assertions due to garbage collector

Status: RESOLVED INVALID

(Core :: XPConnect, defect)

Description

[Dave Townsend [:mossop]]

My extension causes a number of assertions about thread unsafety in nsDirEnumerator and nsBinaryInputStream. The problem is that while I create and use these objects in a single thread, it appears that the garbage collector releases them in a different thread and so an assertion is displayed.

An example stack trace from such an assertion:

xpcom_core.dll!Break(const char * aMsg=0x00000000)  Line 471	C++
xpcom_core.dll!NS_DebugBreak_P(unsigned int aSeverity=, const char * aStr=, const char * aExpr=, const char * aFile=, int aLine=)  Line 356	C++
xpcom_core.dll!nsDirEnumerator::Release()  Line 771 + 0x4f bytes	C++
xpc3250.dll!XPCJSRuntime::GCCallback(JSContext * cx=0x02dc29a8, JSGCStatus status=JSGC_END)  Line 562	C++
gklayout.dll!DOMGCCallback(JSContext * cx=0x02dc29a8, JSGCStatus status=JSGC_END)  Line 2206 + 0x14 bytes	C++
js3250.dll!js_GC(JSContext * cx=0x02dc29a8, unsigned int gcflags=0)  Line 2255	C
js3250.dll!js_ForceGC(JSContext * cx=0x02dc29a8, unsigned int gcflags=0)  Line 1753 + 0x1f bytes	C
js3250.dll!JS_GC(JSContext * cx=0x02dc29a8)  Line 1904 + 0x8 bytes	C
gklayout.dll!nsJSContext::Notify(nsITimer * timer=0x00ba3cb0)  Line 2166	C++
xpcom_core.dll!nsTimerImpl::Fire()  Line 416	C++
xpcom_core.dll!nsTimerEvent::Run()  Line 486	C++
xpcom_core.dll!nsThread::ProcessNextEvent(int mayWait=1, int * result=0x0012fdb8)  Line 483	C++
xpcom_core.dll!NS_ProcessNextEvent_P(nsIThread * thread=0x00000001, int mayWait=1)  Line 225 + 0xd bytes	C++
gkwidget.dll!nsBaseAppShell::Run()  Line 119 + 0x9 bytes	C++
tkitcmps.dll!nsAppStartup::Run()  Line 171	C++
xul.dll!XRE_main(int argc=3, char * * argv=0x003a7248, const nsXREAppData * aAppData=0x004036cc)  Line 2345	C++
firefox.exe!main(int argc=3, char * * argv=0x003a7248)  Line 61 + 0x13 bytes	C++
firefox.exe!__tmainCRTStartup()  Line 586 + 0x19 bytes	C
firefox.exe!mainCRTStartup()  Line 403	C

Comment 1

[Christian :Biesinger (don't email me, ping me on IRC)]

-> xpconnect, I think

Comment 2

[timeless]

i have the beginnings (really just beginnings, it has basic queuing of object death and some arrangements for tracking object creation, probably not much of the how to recognize when it's safe to abandon a thread.) of a patch for this and brendan doesn't like the idea of me doing it without a design doc. anyway, i think the changes i've made can be found on viper or boffo 

Comment 4

[Ryan VanderMeulen [:RyanVM]]

Is this still valid?

Comment 5

[Dave Townsend [:mossop]]

(In reply to Ryan VanderMeulen from comment #4)
> Is this still valid?

I guess since we no longer allow JS to create XPCOM objects off the main thread probably not