83930 - A typo in PR_LockFile in pr/src/io/prfile.c.

Status: RESOLVED FIXED

(NSPR :: NSPR, defect, P1)

Description

[Wan-Teh Chang]

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?

Comment 1

[Wan-Teh Chang]

I've fixed that typo in the trunk of NSPR.

Comment 2

[Wan-Teh Chang]

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.