Thread (54 messages) 54 messages, 5 authors, 2019-03-28

Re: BUG: Race condition due to reflog expiry in "gc"

From: Junio C Hamano <hidden>
Date: 2019-03-13 01:44:02

Possibly related (same subject, not in this thread)

Ævar Arnfjörð Bjarmason [off-list ref] writes:
I'm still working on fixing a race condition I encountered in "gc"
recently, but am not 100% sure of the fix. So I thought I'd send a
braindump of what I have so far in case it jolts any memories.

The problem is that when we "gc" we run "reflog expire --all". This
iterates over the reflogs, and takes a *.lock for each reference.

It'll fail intermittendly in two ways:

 1. If something is concurrently committing to the repo it'll fail
    because we for a tiny amount of time hold a HEAD.lock file, so HEAD
    can't be updated.

 2. On a repository that's just being "git fetch"'d by some concurrent
    process the "gc" will fail, because the ref's SHA1 has changed,
    which we inspect as we aquire the lock.
Both sounds very much expected and expectable outcome.  I am not
sure how they need to be called bugs.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help