[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