296119 - Hang on shutdown when JS_DestroyContext is called recursively

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect, P1)

Description

[David :Bienvenu]

I'm running into a hang on shutdown - so far, I've only seen it in my tree when
I open a .eml file from the command line, but I'm wondering if that's just
exposing some underlying problem. You'll note that js_GC appears twice in the
stack trace, and the hang is here:

http://lxr.mozilla.org/seamonkey/source/js/src/jscntxt.c#266

Note that we're in nested calls to js_DestroyContext. We return out of js_GC on
this line:

http://lxr.mozilla.org/seamonkey/source/js/src/jsgc.c#1584

and thus gcPoke never gets cleared, and we loop forever...

js_GC(JSContext * 0x02af8610, unsigned int 0x00000002) line 1584
js_DestroyContext(JSContext * 0x02af8610, int 0x00000002) line 267 + 11 bytes
JS_DestroyContext(JSContext * 0x02af8610) line 945 + 11 bytes
nsJSContext::~nsJSContext() line 733 + 13 bytes
nsJSContext::`scalar deleting destructor'(unsigned int 0x00000001) + 15 bytes
nsJSContext::Release(nsJSContext * const 0x02af67d8) line 760 + 215 bytes
nsCOMPtr<nsIScriptContext>::assign_assuming_AddRef(nsIScriptContext *
0x00000000) line 569
nsCOMPtr<nsIScriptContext>::assign_with_AddRef(nsISupports * 0x00000000) line 1225
nsCOMPtr<nsIScriptContext>::operator=(nsIScriptContext * 0x00000000) line 714
nsXBLDocGlobalObject::SetContext(nsIScriptContext * 0x00000000) line 181
nsXBLDocumentInfo::~nsXBLDocumentInfo() line 365
nsXBLDocumentInfo::`scalar deleting destructor'(unsigned int 0x00000001) + 15 bytes
nsXBLDocumentInfo::Release(nsXBLDocumentInfo * const 0x02b01010) line 341 + 215
bytes
nsCOMPtr<nsIXBLDocumentInfo>::~nsCOMPtr<nsIXBLDocumentInfo>() line 584
nsBaseHashtableET<nsURIHashKey,nsCOMPtr<nsIXBLDocumentInfo>
>::~nsBaseHashtableET<nsURIHashKey,nsCOMPtr<nsIXBLDocumentInfo> >() line 315 +
18 bytes
nsBaseHashtableET<nsURIHashKey,nsCOMPtr<nsIXBLDocumentInfo> >::`scalar deleting
destructor'(unsigned int 0x00000000) + 15 bytes
nsTHashtable<nsBaseHashtableET<nsURIHashKey,nsCOMPtr<nsIXBLDocumentInfo> >
>::s_ClearEntry(PLDHashTable * 0x02aaa364, PLDHashEntryHdr * 0x02af1684) line 404
PL_DHashTableFinish(PLDHashTable * 0x02aaa364) line 343 + 16 bytes
nsTHashtable<nsBaseHashtableET<nsURIHashKey,nsCOMPtr<nsIXBLDocumentInfo> >
>::~nsTHashtable<nsBaseHashtableET<nsURIHashKey,nsCOMPtr<nsIXBLDocumentInfo> >
>() line 315 + 9 bytes
nsBaseHashtable<nsURIHashKey,nsCOMPtr<nsIXBLDocumentInfo>,nsIXBLDocumentInfo
*>::~nsBaseHashtable<nsURIHashKey,nsCOMPtr<nsIXBLDocumentInfo>,nsIXBLDocumentInfo
*>() + 15 bytes
nsInterfaceHashtable<nsURIHashKey,nsIXBLDocumentInfo>::~nsInterfaceHashtable<nsURIHashKey,nsIXBLDocumentInfo>()
+ 15 bytes
nsBindingManager::~nsBindingManager() line 328 + 43 bytes
nsBindingManager::`scalar deleting destructor'(unsigned int 0x00000001) + 15 bytes
nsBindingManager::Release(nsBindingManager * const 0x02aaa2b0) line 297 + 212 bytes
nsCOMPtr<nsIBindingManager>::~nsCOMPtr<nsIBindingManager>() line 584
nsIDocument::~nsIDocument() line 734 + 55 bytes
nsDocument::~nsDocument() line 679 + 397 bytes
nsHTMLDocument::~nsHTMLDocument() line 295 + 162 bytes
nsHTMLDocument::`scalar deleting destructor'(unsigned int 0x00000001) + 15 bytes
nsDocument::Release(nsDocument * const 0x02aaa028) line 735 + 236 bytes
nsHTMLDocument::Release(nsHTMLDocument * const 0x02aaa028) line 298 + 12 bytes
nsHTMLDocumentSH::ReleaseDocument(JSContext * 0x032872f8, JSObject * 0x01b88c08)
line 6766 + 18 bytes
js_FinalizeObject(JSContext * 0x032872f8, JSObject * 0x01b88c08) line 2041 + 106
bytes
js_GC(JSContext * 0x032872f8, unsigned int 0x00000000) line 1830 + 11 bytes
js_ForceGC(JSContext * 0x032872f8, unsigned int 0x00000000) line 1502 + 13 bytes
js_DestroyContext(JSContext * 0x032872f8, int 0x00000002) line 284 + 11 bytes
JS_DestroyContext(JSContext * 0x032872f8) line 945 + 11 bytes
XPCJSContextStack::~XPCJSContextStack() line 60 + 13 bytes
XPCJSContextStack::`scalar deleting destructor'(unsigned int 0x00000001) + 15 bytes
XPCPerThreadData::CleanupAllThreads() line 543 + 37 bytes
nsXPConnect::~nsXPConnect() line 148
nsXPConnect::`scalar deleting destructor'(unsigned int 0x00000001) + 15 bytes
nsXPConnect::Release(nsXPConnect * const 0x00bbaee0) line 48 + 147 bytes
nsScriptSecurityManager::Shutdown() line 2897 + 26 bytes

Comment 1

[Brendan Eich [:brendan]]

Attachment: proposed fix

This cleans up a bogo-patch I applied a while ago to prop_iterator_finalize,
and rationalizes the relationship between gcPoke (something may have cut a link
in the live object graph) and gcLevel (a finalizer or similar GC-called hook
nested an attempt to run the GC).

/be

Comment 2

[David :Bienvenu]

that does fix the hang I was seeing, thx!

Comment 3

[Mike Shaver (:shaver emeritus)]

Comment on attachment 184954 [details] [diff] [review]
proposed fix

r=shaver.  Always nice to have some cleanup, too!

Comment 4

[Brendan Eich [:brendan]]

David, is this something that needs to be in 1.8b2/{fx,tb}1.1a1?

/be

Comment 5

[David :Bienvenu]

I don't know but I doubt it - the only way I have of recreating this is with
some code in my tree that's NOT in 1.1a. The key thing for recreating this is to
have tbird open a stand-alone msg window as the only window, and then shutdown.
Without the unchecked-in code in my tree, that's not possible. 

I think this bug is exposed by unusual component load and hence shutdown order,
so there might be other ways of recreating it, but the only possibility I can
think of from the mailnews pov is clicking on a mailto: link, and that didn't
cause the problem when I tried it. There is a problem with launching with a
mailto link, but I can't think of a way to blame that problem on this bug.

Comment 6

[Brendan Eich [:brendan]]

Fixed.

/be