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)

4.1.1
x86
Windows NT
defect

Tracking

(Not tracked)

RESOLVED FIXED

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?
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
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.