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: Eli Zaretskii <eliz <at> gnu.org>
Cc: 76187 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu
Subject: bug#76187: vc-git-test-dir-branch-headers failure on Fedora
Date: Fri, 14 Feb 2025 08:51:39 +0100

[Message part 1 (text/plain, inline)]

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

>>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>> 
>>> > 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.
>>> 
>>> Apologies if my brain is too fried and I misunderstood: didn't I show
>>> that this error shows up without parallelism?
>>
>> If that is true, it means _my_ brain is fried, but then how is that
>> other Git process invoked, and by whom?  IOW, which process locked the
>> repository exactly while we were running Git from the test?
>
> No clue thus far.  You mention Git's automatic GC and that's one of my
> scapegoats; another is vc-dir spawning more things than I realize.

With the attached debugging patch (same as [1], plus binding
vc-command-messages to t), I get these traces when the failure happens:

    Running 8 tests (2025-02-14 08:17:56+0100, selector `(not (or (tag :unstable) (tag :nativecomp)))')
       passed  1/8  vc-git-test-annotate-time (0.002302 sec)
    Running in foreground: git --no-pager clone /tmp/emacs-test-go8R94-vc-git/ /tmp/emacs-test-NVSvcg-vc-git/ .
    Done (status=0): git --no-pager clone /tmp/emacs-test-go8R94-vc-git/ /tmp/emacs-test-NVSvcg-vc-git/ .
    Running in foreground: git --no-pager config --get remote.origin.url
    Done (status=0): git --no-pager config --get remote.origin.url
    Running in background: git --no-pager update-index --refresh .
    Done in background: git --no-pager update-index --refresh .
    Running in background: git --no-pager diff-index --relative -z -M HEAD -- .
    Done in background: git --no-pager diff-index --relative -z -M HEAD -- .
    Running in background: git --no-pager ls-files -z -u -- .
    Done in background: git --no-pager ls-files -z -u -- .
    Running in background: git --no-pager ls-files -z -o --exclude-standard -- .
    Done in background: git --no-pager ls-files -z -o --exclude-standard -- .
    Paused 1 time(s) waiting for vc-dir-busy
    Running in foreground: git --no-pager config --get remote.origin.url
    Done (status=0): git --no-pager config --get remote.origin.url
    Running in background: git --no-pager update-index --refresh .
    Running in foreground: git --no-pager checkout -b feature/foo master .
    err in /tmp/emacs-test-NVSvcg-vc-git/: (error Failed (status 128): git --no-pager checkout -b feature/foo master .)
    (buffer-string:
    fatal: Unable to create '/tmp/emacs-test-NVSvcg-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.

    )

Looking at vc-dir-refresh (invoked from vc-dir-revert-buffer-function,
invoked by the testcase reverting the vc-dir buffer), I'd conclude that
the sequence of events is (lighting a candle to the Muse of Manual
Whitespace Adjustment; citing evidence with "> TRACES")

* vc-git-test--dir-headers
  * revert-buffer
    * vc-dir-refresh
      * vc-dir-headers
        * vc-git-dir-extra-headers (👈 the code under test)
          > Running in foreground: git --no-pager config --get remote.origin.url
          > Done (status=0): git --no-pager config --get remote.origin.url
      * "asynchronous-looking things"
        > Running in background: git --no-pager update-index --refresh .
        (⚠️ no proof of termination) 
* vc-git-test--run "checkout" "-b" "feature/foo" main-branch
  * vc-git-test--wait (lambda () (file-exists-p ".git/index.lock"))
    > 🦗 [no log, ergo no lock file detected]
  * vc-git-command 
    > Running in foreground: git --no-pager checkout -b feature/foo master .
    (⚠️ presumably the concurrent locking happens around here)
    > fatal: Unable to create '/tmp/emacs-test-NVSvcg-vc-git/.git/index.lock': File exists.

I think 'git update-index' is a good suspect: cursory glance at
builtin/update-index.c:cmd_update_index confirms that it unconditionally
does:

	newfd = repo_hold_locked_index(the_repository, &lock_file, 0);

Bottomline:

* maybe we could amend the testcase to sync with this background
command,
* unclear whether we should; barring fault in my logic, I stand by my
opinion in [2] and would prefer to install the patch in that message, on
the grounds that contending with vc-dir's asynchrony is outside the
scope of this test (to wit: testing the extra-headers logic).


[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=76187#35
[2] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=76187#53

[more-debug.patch (text/x-patch, attachment)]

Previous Next

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