Re: Anyone know why git ls-remote output might be corrupted?

From: Jeff King <peff@peff.net>
Date: Jun 4, 2023, 06:00 UTC
Message-ID: <20230604060048.GA38176@coredump.intra.peff.net>
In-Reply-To: <CABPp-BF9Xjww=BBkL4qQcENo-UCHd8eEj334ho1iO1EMbGxhZw@mail.gmail.com>

On Fri, Jun 02, 2023 at 06:12:52PM -0700, Elijah Newren wrote:

Show 20 quoted lines

> > Also a bunch of the heads are missing.  It's pretty clear that right in
> > the middle of printing one of the SHAs we suddenly lost a bunch of
> > output, and started printing stuff from later (in the last instance 66
> > out of 131 heads were missing).  Breaking down the output above you can
> > see:
> >
> >   3a2e8036a6f6605d4dd14c72bd395298bff9d80e        refs/heads/xxx2
> >   795d2ff669041fc91341cf5bf820aibab79dc92bd741e77a7dcf71d94285a6ae494dc0        refs/heads/yyy1
> >                                ^
> >
> > where the "795d2ff669041fc91341cf5bf820a" before the "i" char is a
> > valid start of a SHA for a head (not shown), then the "i", then a fully
> > valid SHA for heads/yyy1 which is 66 heads later.
> 
> Sounds kind of like
> https://lore.kernel.org/git/6786526.72e2EbofS7@devpool47/ which also
> triggered for some other tooling and then was reduced down to some
> shell commands.  Unfortunately, the thread ended without a lot of
> resolution other than "don't mix stdout and stderr" and "if we slow
> down the network connection somehow, that'll avoid the problem".

Thanks for digging up that thread. I had a vague memory of this coming up before, but wasn't sure what to search for to find it. :)

From that thread, one theory that I think remains unexplored: could ls-remote's stdout be opened in non-blocking mode?

The output of ls-remote is written with printf(). We don't bother checking for errors from stdio, since typically a write error would result in us getting EPIPE and being killed. But if stdout were unexpectedly in non-blocking mode, we might get EAGAIN. I'm not sure how libc would handle that.

Now, why the descriptor would be in non-blocking mode, I have no idea. But maybe something funny going on in your python script.

I'd be curious if applying the patch from:

  https://lore.kernel.org/git/YUTo1BTp7BXOw6K9@coredump.intra.peff.net/

reports any problems. As well as whether the suggested "sleep" pipeline there (triggered via your script in this case) shows the problem more reliably.

-Peff