PR_UnloadLibrary takes a parameter which wraps an os library reference and then performs two tasks: nspr logging os native calls to unload the library my application tends to hold references to libraries past the time when the nspr logging module is shutdown, which means that calling PR_UnloadLibrary will crash. when my application calls PR_UnloadLibrary after nspr logging is shutdown, it does not need logging output (if necessary i can add my own printfs), what it does need is for the function call the os native unloadlibrary method. With a few simple changes to PR_UnloadLibrary (and bug 204201's introduction of PR_GetLogModule) it is possible for PR_UnloadLibrary to be used safely after nspr is shutdown.
Created attachment 124585 [details] [diff] [review] Check for linkerlock and always get the logmodule
After NSPR is shut down, no NSPR functions may be called. I am sorry that I can't make this change. Can you redesign your code so that it calls PR_UnloadLibrary before NSPR is shut down? Also, you don't need to shut down NSPR (PR_Cleanup).
Breakpoint 2, PR_Cleanup () at /mnt/ibm/mozhack/mozilla/nsprpub/pr/src/pthreads/ptthread.c:913 913 PRThread *me = PR_CurrentThread(); (gdb) where #0 PR_Cleanup () at /mnt/ibm/mozhack/mozilla/nsprpub/pr/src/pthreads/ptthread.c:913 #1 0x4029c4f4 in NS_ShutdownXPCOM (servMgr=0x0) at /mnt/ibm/mozhack/mozilla/xpcom/build/nsXPComInit.cpp:786 #2 0x0804c042 in NS_ShutdownXPCOM (servMgr=0x0) at /mnt/ibm/mozhack/mozilla/xpcom/glue/standalone/nsXPCOMGlue.cpp:144 #3 0x08049cf9 in shutdown_xpcom () at /mnt/ibm/mozhack/mozilla/xpcom/tools/registry/regxpcom.cpp:181 #4 0x0804a58b in main (argc=1, argv=0xbffff394) at /mnt/ibm/mozhack/mozilla/xpcom/tools/registry/regxpcom.cpp:397 #5 0x4011017d in __libc_start_main () from /lib/libc.so.6 (gdb) c Continuing. Breakpoint 3, PR_UnloadLibrary (lib=0x805ad60) at /mnt/ibm/mozhack/mozilla/nsprpub/pr/src/linking/prlink.c:1328 1328 int result = 0; (gdb) where #0 PR_UnloadLibrary (lib=0x805ad60) at /mnt/ibm/mozhack/mozilla/nsprpub/pr/src/linking/prlink.c:1328 #1 0x0804bf9d in XPCOMGlueShutdown () at /mnt/ibm/mozhack/mozilla/xpcom/glue/standalone/nsXPCOMGlue.cpp:120 #2 0x08049d26 in shutdown_xpcom () at /mnt/ibm/mozhack/mozilla/xpcom/tools/registry/regxpcom.cpp:187 #3 0x0804a58b in main (argc=1, argv=0xbffff394) at /mnt/ibm/mozhack/mozilla/xpcom/tools/registry/regxpcom.cpp:397 #4 0x4011017d in __libc_start_main () from /lib/libc.so.6 (gdb) up #1 0x0804bf9d in XPCOMGlueShutdown () at /mnt/ibm/mozhack/mozilla/xpcom/glue/standalone/nsXPCOMGlue.cpp:120 120 PR_UnloadLibrary(xpcomLib); Current language: auto; currently c++ (gdb) app in question: regxpcom (glued ver). perhaps xpcomglue shouldn't use nspr? I could change it so that each app has to manually call PR_Cleanup *after* it calls NS_ShutdownXPCOM, but the thing is that the app didn't explicitly call anything to initialize nspr, so i don't think it's right for the app to be expected to call something to clean it up (all the app did was call NS_InitXPCOM2).
If XPCOMGlueShutdown is called after NS_ShutdownXPCOM and NS_ShutdownXPCOM calls PR_Cleanup, XPCOMGlueShutdown must not call any NSPR functions. As timeless pointed out, the possible solutions are: 1. do not call PR_Cleanup in NS_ShutdownXPCOM; or 2. do not use NSPR in XPCOMGlue. It is fine to not call PR_Cleanup. The only drawback is that Purify will report some memory leaks of the data allocated by NSPR for internal use. Those leaks can be safely ignored. Doug, weren't you working on a NSPR-free version of XPCOMGlue?
Indeed, I am working on a NSPR-free version of XPCOMGlue. However, this is a low priority atm.
wtc: that xpcomglue stuff was killed, the problem still exists.
It's not dead, just very hard.
wtc, dougt, is this still relevant and should a patch be done? If so, it should get onto the list of someone working on it, not sure if timeless is really active these days. If not, let's resolve this bug some way so it gets off the "open crashers" list.
I do not think we have any immediate need for this.