Closed
Bug 83930
Opened 23 years ago
Closed 23 years ago
A typo in PR_LockFile in pr/src/io/prfile.c.
Categories
(NSPR :: NSPR, defect, P1)
Tracking
(Not tracked)
RESOLVED
FIXED
4.1.2
People
(Reporter: wtc, Assigned: larryh)
References
()
Details
I found a typo in the PR_LockFile function in pr/src/io/prfile.c. The assignment statement fd->secret->lockCount = -1; was incorrectly typed in as fd->secret->lockCount == -1; That implementation is only used by Windows. The version used by Unix flavors (in pr/src/pthreads/ptio.c) does not have this typo. This bug only affects the condition when a thread is in the middle of calling the native lock file system call and another thread tries to lock the same file at that time. This could be why it was not detected by our 'lockfile' test because our test may not be able to create that condition. Chris, do you remember what happens on NT if a thread owns a file lock and another thread in the same process tries to lock the same file? Does the lockfile operation fail with a deadlock error or block until the first thread releases its file lock?
Reporter | ||
Updated•23 years ago
|
Status: NEW → ASSIGNED
Priority: -- → P1
Target Milestone: --- → 4.1.2
Reporter | ||
Comment 1•23 years ago
|
||
I've fixed that typo in the trunk of NSPR.
Reporter | ||
Comment 2•23 years ago
|
||
I fixed the typo on the NSPRPUB_RELEASE_4_1_BRANCH as well, in preparation for the NSPR 4.1.2 release. Note that this bug was introduced in NSPR 4.1.1, in my fix for bug #70295.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Version: 4.1 → 4.1.1
You need to log in
before you can comment on or make changes to this bug.
Description
•