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?
Status: NEW → ASSIGNED
Priority: -- → P1
Target Milestone: --- → 4.1.2
I've fixed that typo in the trunk of NSPR.
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
Last Resolved: 17 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.