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

Previous Next

Full log

View this message in rfc822 format

From: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 76187 <at> debbugs.gnu.org
Subject: bug#76187: vc-git-test-dir-branch-headers failure on Fedora
Date: Tue, 11 Feb 2025 23:09:45 +0100

Kévin Le Gouguec <kevin.legouguec <at> gmail.com> writes:

> Paul Eggert <eggert <at> cs.ucla.edu> writes:
>
>> On 2/11/25 12:43, Kévin Le Gouguec wrote:
>>> Another git process seems to be running in this repository,
>>
>> I guess the test won't work with "make -j check", since some other test might also be running git in that repository. If my guess is right, to fix this you can arrange for the test to run in a clone instead. Similarly for any other test that might want to alter that repository or its working files.
>
> The test does arrange to run in isolated directories, using
> ert-with-temp-directory:
>
> (defmacro vc-git-test--with-repo (name &rest body)
>   ;; …
>   `(ert-with-temp-directory ,name
>      (let ((default-directory ,name)
>            ;; …
>            )
>        (vc-create-repo 'Git)
>        ,@body)))
>
> (ert-deftest vc-git-test-dir-branch-headers ()
>   ;; …
>   ;; Create a repository that will serve as the "remote".
>   (vc-git-test--with-repo origin-repo                                   
>     (let ((main-branch (vc-git-test--start-branch)))
>       ;; 'git clone' this repository and test things in this clone.
>       (ert-with-temp-directory clone-repo
>         ;; …
>         ))))
>
> So unless I am missing something, 'make -j' ought not be a factor.
>
> My current working theories are:
>
> a. We fail to sync with some asynchronous processes spawned by vc before
>    running these 'git checkout' commands; there is precedent for
>    synchronization problems:
>
>      (defun vc-git-test--dir-headers (headers)
>        "…"
>        ;; FIXME: to reproduce interactive sessions faithfully, we would need
>        ;; to wait for the dir-status-files process to terminate; have not
>        ;; found a reliable way to do this.  As a workaround, kill pending
>        ;; processes and revert the `vc-dir' buffer.
>        (vc-dir-kill-dir-status-process)
>        (revert-buffer)
>        ;; …
>        )
>
>    FWIW, sticking one more speculative (vc-dir-kill-dir-status-process)
>    after (revert-buffer) lowers the failure rate (took 10 minutes to
>    reproduce it once; no second occurrence after >5k runs over 30min).
>
> b. One of the test's git commands spawns a… background GC job or
>    something, and the test's next git command trips over that.

c. That vc-dir-kill-dir-status-process actually kills a Git process that
   is "holding the lock", in which case…

> I suppose either a or b would be solved by vc-git-test--run spinning for
> a bit while (file-exists-p "…/index.lock"); ideally though I'd prefer to
> catch the locking process red-handed… not sure how to achieve this
> though.

… this will not work.

I'd like to believe that the present bug stems from that dodgy FIXME
workaround, and addressing the latter will fix the former, but that
FIXME was an admission of defeat already.  Haven't grown wiser since
then unfortunately.

(No luck reproducing any of this under strace FWIW)

Previous Next

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