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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

> > 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@xxxxxxxxxxxxxxxxxxxxxxx/

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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux