207668 - Allow PR_UnloadLibrary to be called after logging modules are shutdown

Status: REOPENED

(NSPR :: NSPR, defect)

Description

[timeless]

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.

Comment 1

[timeless]

Attachment: Check for linkerlock and always get the logmodule

Comment 2

[Wan-Teh Chang]

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).

Comment 3

[timeless]

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).

Comment 4

[Wan-Teh Chang]

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?

Comment 5

[Doug Turner (:dougt)]

Indeed, I am working on a NSPR-free version of XPCOMGlue.  However, this is a
low priority atm.

Comment 6

[timeless]

wtc: that xpcomglue stuff was killed, the problem still exists.

Comment 7

[Benjamin Smedberg]

It's not dead, just very hard.

Comment 8

[Robert Kaiser]

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.

Comment 9

[Doug Turner (:dougt)]

I do not think we have any immediate need for this.

Comment 10

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee is inactive on Bugzilla, so the assignee is being reset.