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

RESOLVED FIXED in 4.1.2

Status

NSPR
NSPR
P1
normal
RESOLVED FIXED
17 years ago
15 years ago

People

(Reporter: Wan-Teh Chang, Assigned: larryh (gone))

Tracking

4.1.1
4.1.2
x86
Windows NT

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

17 years ago
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

17 years ago
Status: NEW → ASSIGNED
Priority: -- → P1
Target Milestone: --- → 4.1.2
(Reporter)

Comment 1

17 years ago
I've fixed that typo in the trunk of NSPR.
(Reporter)

Comment 2

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