From: Jeff King <peff@peff.net>
Date: Wed, 08 Apr 2026 17:37:14 GMT
Subject: Re: Git 2.54.0-rc1, subtests of t5310, t5326, t5327
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:

> 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