[Bug 3506] New: race condition in trylock/testlock
bugzilla-daemon at bz.selenic.com
bugzilla-daemon at bz.selenic.com
Wed Jun 20 07:22:19 CDT 2012
http://bz.selenic.com/show_bug.cgi?id=3506
Priority: normal
Bug ID: 3506
CC: mercurial-devel at selenic.com
Assignee: bugzilla at selenic.com
Summary: race condition in trylock/testlock
Severity: bug
Classification: Unclassified
OS: Linux
Reporter: asuffiel at cisco.com
Hardware: All
Status: UNCONFIRMED
Version: unspecified
Component: Mercurial
Product: Mercurial
mercurial.lock.trylock can follow this sequence of events:
call util.makelock
get EEXIST because somebody else has it locked
the other process that has the lock releases it at this point, deleting the
symlink
call self.testlock
-> call util.readlock
-> call os.readlink
-> get ENOENT
-> raise, because it's not EINVAL or ENOSYS
we're not inside any exception handler here, so OSError is propagated up the
call stack, eventually aborting the whole operation
The correct behavior is of course to swallow ENOENT in trylock and go back
around the loop - the lock was just released so this process should try to take
it.
--
You are receiving this mail because:
You are on the CC list for the bug.
More information about the Mercurial-devel
mailing list