Allow PR_UnloadLibrary to be called after logging modules are shutdown

REOPENED
Assigned to

Status

NSPR
NSPR
--
enhancement
REOPENED
15 years ago
4 years ago

People

(Reporter: timeless, Assigned: timeless)

Tracking

(Depends on: 1 bug, {crash})

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

15 years ago
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.
(Assignee)

Comment 1

15 years ago
Created attachment 124585 [details] [diff] [review]
Check for linkerlock and always get the logmodule
(Assignee)

Updated

15 years ago
Attachment #124585 - Flags: review?(wtc)

Comment 2

15 years ago
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).
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → WONTFIX
(Assignee)

Comment 3

15 years ago
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

15 years ago
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

15 years ago
Indeed, I am working on a NSPR-free version of XPCOMGlue.  However, this is a
low priority atm.
(Assignee)

Comment 6

13 years ago
wtc: that xpcomglue stuff was killed, the problem still exists.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---

Comment 7

13 years ago
It's not dead, just very hard.
QA Contact: wtchang → nspr

Comment 8

6 years ago
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.

Updated

4 years ago
Flags: needinfo?(wtc)
Flags: needinfo?(doug.turner)

Comment 9

4 years ago
I do not think we have any immediate need for this.
Flags: needinfo?(wtc)
Flags: needinfo?(doug.turner)
You need to log in before you can comment on or make changes to this bug.