Closed
Bug 2227
Opened 26 years ago
Closed 26 years ago
PR_CEnterMonitor does not initialize NSPR implicitly.
Categories
(NSPR :: NSPR, defect, P2)
NSPR
NSPR
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.
Assignee | ||
Updated•26 years ago
|
Status: NEW → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 1•26 years ago
|
||
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)
Comment 2•26 years ago
|
||
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?
Assignee | ||
Comment 3•26 years ago
|
||
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.
Updated•26 years ago
|
Status: RESOLVED → VERIFIED
Comment 4•26 years ago
|
||
marking verified unless anyone disagrees
Comment 5•25 years ago
|
||
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.
Description
•