Closed Bug 2227 Opened 26 years ago Closed 26 years ago

PR_CEnterMonitor does not initialize NSPR implicitly.

Categories

(NSPR :: NSPR, defect, P2)

defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: wtc, Assigned: wtc)

Details

This bug is reported by Radha Kulkarni <radha@netscape.com>. I wrote a test program that calls PR_CEnterMonitor() at the very beginning of the main() function. It crashed because NSPR was not initialized: Program received signal SIGSEGV, Segmentation fault. 0xef72acd0 in CreateMonitor (address=0xeffff964) at prcmon.c:237 237 while ((p = *pp) != 0) { (gdb) where #0 0xef72acd0 in CreateMonitor (address=0xeffff964) at prcmon.c:237 #1 0xef72b01c in PR_CEnterMonitor (address=0xeffff964) at prcmon.c:307 #2 0x1127c in main () at cmon.c:10 (gdb) print pp $1 = (MonitorCacheEntry **) 0x0 The fix is to add a _PR_ImplicitInitialization() call to the beginning of PR_CEnterMonitor(): Index: prcmon.c =================================================================== RCS file: /m/src/ns/nspr20/pr/src/threads/prcmon.c,v retrieving revision 2.1 diff -c -r2.1 prcmon.c *** prcmon.c 1998/04/16 21:25:26 2.1 --- prcmon.c 1999/01/08 00:15:41 *************** *** 303,308 **** --- 303,310 ---- { PRMonitor *mon; + if (!_pr_initialized) _PR_ImplicitInitialization(); + _PR_LOCK_MCACHE(); mon = CreateMonitor(address); _PR_UNLOCK_MCACHE(); To work around the bug, you can add a dummy PR_GetCurrentThread() call before the problematic PR_CEnterMonitor() call. The PR_GetCurrentThread() call forces NSPR to initialize. Rick, Radha, can you try out the fix (if you build NSPR from the source) or the workaround? Thanks.
Status: NEW → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
Fixed on the tip. /cvsroot/mozilla/nsprpub/pr/src/threads/prcmon.c, revision 3.2. (Also in the internal CVS repository /m/src/ns/nspr20/pr/src/threads/prcmon.c, revision 2.2)
Unix uses the binary release of NSPR 2.1. To make this checkin effective for unix, I guess we have to rebuild NSPR 2.1 with the proposed change. Am I right?
Actually, the version of NSPR release that Mozilla is using on Unix is v3.0. The "21" in "-lnspr21" indicates binary compatibility level, not the version number. Since Rick has checked in my suggested workaround, Mozilla (Sea Monkey) does not need my NSPR fix right now. When we make a new NSPR release that includes this fix, we will need to remove the temporary workaround.
Status: RESOLVED → VERIFIED
marking verified unless anyone disagrees
NSPR now has its own Bugzilla product. Moving this bug to the NSPR product.
You need to log in before you can comment on or make changes to this bug.