Race condition checking lock files

RESOLVED DUPLICATE of bug 151188

Status

--
minor
RESOLVED DUPLICATE of bug 151188
17 years ago
17 years ago

People

(Reporter: pc_junk, Assigned: ccarlen)

Tracking

Details

(Reporter)

Description

17 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.0) Gecko/20020820
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.0) Gecko/20020820

It appears that Navigator uses the PID embedded in the lock file symbolic link
(lock -> 0.0.0.0:####) to test whether there is another instance of Navigator
running. There is a potential race condition here if Navigator closes
unexpectedly without clearing the lock file and by the time the user attempts to
restart the system PID has wrapped around such that another process is using
this PID. In this case navigator will refuse to restart and display a message
stating that another instance is running. I assume that Navogator is kist doing
a kill(pid,0) to check if the process exists rather than verifying that it is
actually an instance of Navigator.

Although this may sound unlikely it actually happened to me following a power
outage and I needed to manually delete the lock file to be able to start Navigator.

Reproducible: Always

Steps to Reproduce:
This can be reproduced artificially however the chance of it actually happening
to a user are fairly slim (but definitely possible)

a. Quit Navigator
b. Create a dummy lock file pointing to an existing process:
   $ ln -fs 0.0.0.0:PID lock
c. Attempt to start Navigator
Actual Results:  
Error dialog displayed stating that another instance is running

Expected Results:  
Navigator should attempt to check whether the process indicated by the lockfile
is actually a Navigator instance (possibly by inspecting kvm_getprocs) or at the
least offer an option for deleing the lockfile and continuing.

Comment 1

17 years ago
PaulC, is this a problem with Mozilla as well?
IIRC, this actually happened to me once and I could only get rid of the problem
by restarting.

Comment 3

17 years ago
->pinkerton
Assignee: saari → pinkerton
ahhh the dreaded lock file. no way i'm touching this one ;)

-> ccarlen
Assignee: pinkerton → ccarlen
This is a dup.

/be

*** This bug has been marked as a duplicate of 151188 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.