From: Jeff King <peff@peff.net>
To: rsbecker@nexbridge.com
Cc: git@vger.kernel.org
Subject: Re: Git 2.54.0-rc1, subtests of t5310, t5326, t5327
Date: Wed, 8 Apr 2026 13:37:14 -0400 [thread overview]
Message-ID: <20260408173714.GA2850002@coredump.intra.peff.net> (raw)
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
prev parent reply other threads:[~2026-04-08 17:37 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-07 23:29 Git 2.54.0-rc1, subtests of t5310, t5326, t5327 rsbecker
2026-04-08 4:17 ` Jeff King
2026-04-08 14:54 ` rsbecker
2026-04-08 16:25 ` rsbecker
2026-04-08 17:39 ` Jeff King
2026-04-08 18:12 ` Junio C Hamano
2026-04-08 20:08 ` rsbecker
2026-04-08 20:21 ` Junio C Hamano
2026-04-08 21:27 ` rsbecker
2026-04-08 21:43 ` Junio C Hamano
2026-04-08 22:04 ` rsbecker
2026-04-08 22:24 ` Junio C Hamano
2026-04-08 22:35 ` Junio C Hamano
2026-04-08 23:15 ` rsbecker
2026-04-08 22:32 ` Jeff King
2026-04-09 0:20 ` brian m. carlson
2026-04-09 8:17 ` Patrick Steinhardt
2026-04-09 9:48 ` Phillip Wood
2026-04-09 11:29 ` Patrick Steinhardt
2026-04-09 13:46 ` rsbecker
2026-04-09 20:33 ` Jeff King
2026-04-09 22:40 ` rsbecker
2026-04-09 22:58 ` Jeff King
2026-04-10 4:34 ` Patrick Steinhardt
2026-04-09 20:51 ` Jeff King
2026-04-10 7:35 ` Johannes Sixt
2026-04-08 18:36 ` rsbecker
2026-04-08 22:14 ` Jeff King
2026-04-08 17:37 ` Jeff King [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260408173714.GA2850002@coredump.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=rsbecker@nexbridge.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox