GNU bug report logs - #76187
vc-git-test-dir-branch-headers failure on Fedora

Previous Next

Full log

Message #38 received at 76187 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
Cc: 76187 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu
Subject: Re: bug#76187: vc-git-test-dir-branch-headers failure on Fedora
Date: Thu, 13 Feb 2025 09:06:27 +0200

> From: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
> Cc: 76187 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
> Date: Wed, 12 Feb 2025 23:37:19 +0100
> 
> Bafflement continues.  With the attached patch that
> 
> * removes the call to vc-dir-kill-dir-status-process to eliminate
> hypothesis c,
> * replaces it with a (while (vc-dir-busy) …) loop to mitigate a,
> * adds a (while (file-exists-p ".git/index.lock")) loop to mitigate b,
> 
> I still reproduce.  Here, after 700 runs in 6min:
> 
>       GEN      lisp/vc/vc-git-tests.log
>     Running 8 tests (2025-02-12 23:16:08+0100, selector `(not (or (tag :unstable) (tag :nativecomp)))')
>        passed  1/8  vc-git-test-annotate-time (0.002284 sec)
>     Paused 1 time(s) waiting for vc-dir-busy
>     err in /tmp/emacs-test-dhul2y-vc-git/: (error Failed (status 128): git --no-pager checkout -b feature/foo master .)
>     (buffer-string:
>     fatal: Unable to create '/tmp/emacs-test-dhul2y-vc-git/.git/index.lock': File exists.
> 
>     Another git process seems to be running in this repository, e.g.
>     an editor opened by 'git commit'. Please make sure all processes
>     are terminated then try again. If it still fails, a git process
>     may have crashed in this repository earlier:
>     remove the file manually to continue.
> 
>     )
> 
> I have a hard time making sense of the sequence of events.  Evidently:
> 
> 1. vc-git-test--run did *not* pause for (file-exists-p
>    ".git/index.lock"),
> 2. but Git *still* tripped over a preexisting .git/index.lock.
> 
> Logging default-directory in the condition-case error handler confirms
> we are in the correct directory, so I do not understand why
> file-exists-p did not see the lock that Git reports.  All I can think of
> is a stray Git process ¿started at some point by someone? that grabs the
> lock between steps 1 & 2.

Yes, something like that.  A.k.a. "a race condition".

> Barring "turn off background processing" knobs for VC and/or Git that I
> missed, not sure what to try next beside catching that "index.lock
> exists" error and re-trying after a delay.

How about just ignoring the error in this case?  AFAIU, it's rare
enough to not be important, right?  AFAIK, you cannot have more than
one Git instance modifying the repository at any given time, so this
problem cannot be fixed in principle if we are running tow or more Git
sessions in parallel.  IOW, these tests must NOT be run via parallel
make processing.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.