libumem shows we're leaking a JSThread on every shutdown.

Is this a similar|same leak?

wtc, can you remind me (or timeless may if he's watching) why the main thread's js_ThreadDestructorCB might not be running, in time or at all? Thanks, /be

The main thread's NSPR thread private data destructors will only be run if you call PR_Cleanup(). The main thread's pthread thread specific data destructors will only be run if you call pthread_exit(). If you just fall off the main() function, the pthread thread specific data destructors won't be called.

Cc'ing bsmedberg -- is this a dup? If not, it needs to change component. /be

Trace malloc leaks increased substantially with the landing of bug 365851.

Seems like a bug in browser/app/nsBrowserApp.cpp. Patch next. /be

bsmedberg, I welcome your opinion too -- feel free to steal this bug if there is a app-generic fix in toolkit or XPCOM. /be

Comment on attachment 302079 [details] [diff] [review] fix, according to gdb r+a=me, straightforward enough

Comment on attachment 302079 [details] [diff] [review] fix, according to gdb Brendan, we actually added a _fini routine to libnspr4.so that calls the NSPR thread private data destructors for the main thread for several months. But that caused crashes in application code. We fixed one or two crashes. But the third crash, I decided that applications are used to NSPR not calling the main thread's TPD destructors, and removed that code. See bug 383977. So I'm worried that your patch will have the same fate. Also note that after you shut down NSPR, you need to make sure no destructors of C++ static variables and no atexit handlers use NSPR. This is actually why Mozilla is not calling PR_Cleanup.

We do want to destroy the JSThreads mapped by JS's thread-private index, for sane leak accounting. Probably other stuff like that (XPConnect, etc.). What to do? /be

Is there a JS_cleanup function which can set/sets the thread-private value to null? See bug 349463 which solves a reverse xpconnect bug by *not* cleaning up threads after a certain point if we haven't shut them down correctly by then.

Not blocking on this bug for final ship. Would take a safe enough patch if one comes through.

Comment on attachment 302079 [details] [diff] [review] fix, according to gdb Removing approval since this missed the 1.9 cutoff.

Is this still wanted?

This was fixed quite some time ago in another bug.