Re: BUG: Race condition due to reflog expiry in "gc"
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Mar 13, 2019, 01:43 UTC
- Message-ID
- <xmqq1s3bh7ky.fsf@gitster-ct.c.googlers.com>
- In-Reply-To
- <87tvg7brlm.fsf@evledraar.gmail.com>
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
Show 16 quoted lines
> 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.