Re: Git 2.54.0-rc1, subtests of t5310, t5326, t5327

From: Jeff King <peff@peff.net>
Date: Apr 8, 2026, 17:37 UTC
Message-ID: <20260408173714.GA2850002@coredump.intra.peff.net>
In-Reply-To: <011701dcc767$8c2ab400$a4801c00$@nexbridge.com>

On Wed, Apr 08, 2026 at 10:54:00AM -0400, rsbecker@nexbridge.com wrote:

Show 16 quoted lines

> First fail is as follows in subtest 25:
> 
> expecting success of 5310.25 'clone from bitmapped repository':
>                 rm -fr clone.git &&
>                 git clone --no-local --bare . clone.git &&
>                 git rev-parse HEAD >expect &&
>                 git --git-dir=clone.git rev-parse HEAD >actual &&
>                 test_cmp expect actual
> 
> Cloning into bare repository 'clone.git'...
> remote: Enumerating objects: 629, done.
> fatal: writev error: Invalid function argument
> fetch-pack: unexpected disconnect while reading sideband packet
> fatal: early EOF
> fatal: fetch-pack: invalid index-pack output
> not ok 25 - clone from bitmapped repository

OK, good. Well, not good, but at least absolves --git-dir, and we know the problem is just writev() everywhere.

> I think the invalid function argument maybe an ioctl or socketioctl
> not supported for the file type.

Yeah, this is weird. We are just calling writev() here, and not trying to do anything exotic. I could believe that writev() isn't supported on certain descriptor types or something, but this should just be a pipe. But why does it consistently fail here, but not in every clone? Weird.

It might be interesting to use strace or a debugger (or just printf from writev_or_die()) to see if there's something interesting about the arguments here. But finding the root cause may not actually be that helpful (or at least not worth the effort).

Does building with NO_WRITEV make the problem go away?

-Peff