From: Junio C Hamano <hidden> Date: 2021-09-15 18:17:51
Rolf Eike Beer [off-list ref] writes:
The given repository is a clone of the vanilla kernel.
/usr/bin/git --git-dir=/home/ebeer/repos/upstream/linux/.git ls-remote origin 2>&1 | less
And I then see things like this:
6f38b5d6cfd43dde3058a10c68baae9cf17af912 refs/tags/v5.0-rc2
1c7fc5cbc33980acd13ae83d0b416db002fe95601e7f97f64b59514d936 refs/tags/v5.7-rc2^{}
d0709bb6da2ab6d49b11643e98abdf79b1a2817f refs/tags/v5.7-rc3
Not offering any solution, just an observation of the problem and
annotating the report.
What we see on the second line is the beginning of peeled
v5.0-rc2^{} up to the "acd13" (that is, the first 19 bytes of the
line), followed by the full line for peeled v5.7-rc2^{} (which
begins with "ae83d"). 12407 bytes in between are missing, which
is even more puzzling as it is not a nice round number.
I wonder if this is "less" misconfigured and misbehaving. Did the
user after seeing v5.7-* tags scroll back with 'b' or something?
If the output (including the 2>&1 redirection) is sent to a file and
then "cat <that-file" is invoked, does the same thing happen? How
about "cat <that-file | less"?
Am Mittwoch, 15. September 2021, 20:17:42 CEST schrieb Junio C Hamano:
Rolf Eike Beer [off-list ref] writes:
quoted
The given repository is a clone of the vanilla kernel.
/usr/bin/git --git-dir=/home/ebeer/repos/upstream/linux/.git ls-remote
origin 2>&1 | less
And I then see things like this:
6f38b5d6cfd43dde3058a10c68baae9cf17af912 refs/tags/v5.0-rc2
1c7fc5cbc33980acd13ae83d0b416db002fe95601e7f97f64b59514d936
refs/tags/v5.7-rc2^{} d0709bb6da2ab6d49b11643e98abdf79b1a2817f
refs/tags/v5.7-rc3
Not offering any solution, just an observation of the problem and
annotating the report.
What we see on the second line is the beginning of peeled
v5.0-rc2^{} up to the "acd13" (that is, the first 19 bytes of the
line), followed by the full line for peeled v5.7-rc2^{} (which
begins with "ae83d"). 12407 bytes in between are missing, which
is even more puzzling as it is not a nice round number.
I wonder if this is "less" misconfigured and misbehaving. Did the
user after seeing v5.7-* tags scroll back with 'b' or something?
To quote myself:
quoted
This is not bound to less, we originally observed the error on a
entirely different tool that tried to parse the output of ls-remote.
In fact when less opened I just started to scroll down until I visually
noticed an error.
If the output (including the 2>&1 redirection) is sent to a file and
then "cat <that-file" is invoked, does the same thing happen? How
about "cat <that-file | less"?
The redirection seems to be an important part of it. I now did:
git ... 2>&1 | sha256sum
This gives different results basically on every run. I also noticed that
having more tags makes it easier to reproduce, so a stable kernel in contrast
to vanilla is a better trigger. Doing that without the stderr redirection gave
the same result every time I tried.
Regards,
Eike
--
Rolf Eike Beer, emlix GmbH, http://www.emlix.com
Fon +49 551 30664-0, Fax +49 551 30664-11
Gothaer Platz 3, 37083 Göttingen, Germany
Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160
Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055
emlix - smart embedded open source
The redirection seems to be an important part of it. I now did:
git ... 2>&1 | sha256sum
I've tried to reproduce this since yesterday, but couldn't until now:
2>&1 made all the difference, took less than a minute.
Different repo, different machine, but also running Tumbleweed
5.14.1-1-default, git 2.33.0
while [ "`git --git-dir=$PWD/in/linux/.git ls-remote origin 2>&1 | tee
failed.out | sha1sum`" = "7fa299e589bacdc908395730beff542b0fc684eb -"
]; do echo -n .; done
..........
failed.out has multiple lines like this:
--8<--
4e77f7f1261f65cff06918bc5e66d02a418fc842 refs/tags/v3.10.18^{}
f7b8df0cc81cf82a4ac6834225bddbe46a340455a4a5d52f29d08d923ce8d232b0b497da674dd2c
refs/tags/v3.18
b2776bf7149bddd1f4161f14f79520f17fc1d71d refs/tags/v3.18^{}
--8<--
Running the same on Archlinux (5.13.13-arch1-1, 2.33.0) doesn't show the
problem.
This may well turn out not to be git, but a kernel issue.
@Eike: I think at this point you should try to downgrade and see whether
that makes any difference
Am Donnerstag, 16. September 2021, 12:12:48 CEST schrieb Tobias Ulmer:
On 16/09/2021 08:38, Rolf Eike Beer wrote:
...
quoted
The redirection seems to be an important part of it. I now did:
git ... 2>&1 | sha256sum
I've tried to reproduce this since yesterday, but couldn't until now:
2>&1 made all the difference, took less than a minute.
Different repo, different machine, but also running Tumbleweed
5.14.1-1-default, git 2.33.0
while [ "`git --git-dir=$PWD/in/linux/.git ls-remote origin 2>&1 | tee
failed.out | sha1sum`" = "7fa299e589bacdc908395730beff542b0fc684eb -"
]; do echo -n .; done
..........
failed.out has multiple lines like this:
--8<--
4e77f7f1261f65cff06918bc5e66d02a418fc842 refs/tags/v3.10.18^{}
f7b8df0cc81cf82a4ac6834225bddbe46a340455a4a5d52f29d08d923ce8d232b0b497da674d
d2c refs/tags/v3.18
b2776bf7149bddd1f4161f14f79520f17fc1d71d refs/tags/v3.18^{}
--8<--
Running the same on Archlinux (5.13.13-arch1-1, 2.33.0) doesn't show the
problem.
This may well turn out not to be git, but a kernel issue.
Linus,
since you have been hacking around in pipe.c recently, I fear this isn't
entirely impossible. Have you any idea?
For easier reference, the complete thread is at:
https://public-inbox.org/git/85a103f6-8b3c-2f21-cc0f-04f517c0c9a1@emlix.com/T/
Eike
--
Rolf Eike Beer, emlix GmbH, http://www.emlix.com
Fon +49 551 30664-0, Fax +49 551 30664-11
Gothaer Platz 3, 37083 Göttingen, Germany
Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160
Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055
emlix - smart embedded open source
From: Mike Galbraith <hidden> Date: 2021-09-16 15:51:02
On Thu, 2021-09-16 at 14:17 +0200, Rolf Eike Beer wrote:
Am Donnerstag, 16. September 2021, 12:12:48 CEST schrieb Tobias Ulmer:
quoted
On 16/09/2021 08:38, Rolf Eike Beer wrote:
...
quoted
The redirection seems to be an important part of it. I now did:
git ... 2>&1 | sha256sum
I've tried to reproduce this since yesterday, but couldn't until now:
2>&1 made all the difference, took less than a minute.
Different repo, different machine, but also running Tumbleweed
5.14.1-1-default, git 2.33.0
while [ "`git --git-dir=$PWD/in/linux/.git ls-remote origin 2>&1 | tee
failed.out | sha1sum`" = "7fa299e589bacdc908395730beff542b0fc684eb -"
]; do echo -n .; done
..........
failed.out has multiple lines like this:
--8<--
4e77f7f1261f65cff06918bc5e66d02a418fc842 refs/tags/v3.10.18^{}
f7b8df0cc81cf82a4ac6834225bddbe46a340455a4a5d52f29d08d923ce8d232b0b497da674d
d2c refs/tags/v3.18
b2776bf7149bddd1f4161f14f79520f17fc1d71d refs/tags/v3.18^{}
--8<--
Running the same on Archlinux (5.13.13-arch1-1, 2.33.0) doesn't show the
problem.
This may well turn out not to be git, but a kernel issue.
I use git-daemon (2.33) and reference clones for my local pile of
kernel trees (74), so out of curiosity, modified the above ls-remote
loop to fit one of them, and tried to reproduce with both master.today
(ff1ffd71) and SUSE's stable branch (where Tumbleweed gets source,
currently at 5.14.4). Both kernels failed to reproduce given a few
minutes each (zzzz) to do so. I'm running Leap-15.3 vs Tumbleweed, but
that shouldn't matter.
-Mike
On Thu, Sep 16, 2021 at 5:17 AM Rolf Eike Beer [off-list ref] wrote:
Am Donnerstag, 16. September 2021, 12:12:48 CEST schrieb Tobias Ulmer:
quoted
quoted
The redirection seems to be an important part of it. I now did:
git ... 2>&1 | sha256sum
I've tried to reproduce this since yesterday, but couldn't until now:
2>&1 made all the difference, took less than a minute.
So if that redirection is what matters, and what causes problems, I
can almost guarantee that the reason is very simple:
Your git repository (or more likely your upstream) has some problem,
it's getting reported on stderr, and because you mix stdout and stderr
with that '2>&1', you get randomly mixed output.
Then it depends on timing where the mixing happens.
Or rather, it depends on various different factors, like the buffering
done internally by stdio (where stdout generally will be
block-buffered, while stderr is usually line-buffered, which is why
you get odd mixing of the two).
But timing can be an effect particularly with "git ls-remote" and
friends, because you may get errors from the transport asynchronously.
So the different buffering ends up causing the effect of mixing things
in the middle of lines, while the timing differences due to the
asynchronous nature of the remote access pipeline will likely then
cause that odd mixing to be different.
End result: corrupted lines, and different sha256sum every time.
quoted
Running the same on Archlinux (5.13.13-arch1-1, 2.33.0) doesn't show the
problem.
This may well turn out not to be git, but a kernel issue.
Much more likely that the other box just doesn't have the error situation.
since you have been hacking around in pipe.c recently, I fear this isn't
entirely impossible. Have you any idea?
Almost certainly not the kernel. Kernel - and other - differences
could affect timing, of course, but the whole "2>&1" really is
fundamentally bogus.
If you don't have any errors, then the "2>&1" doesn't matter.
And if you *do* have errors, then by definition the "2>&1" will mix in
the errors with the output randomly and piping them together is
senseless.
Either way, it's wrong.
So what I'd suggest Tobias should do is
git ... 2> err | sha256sum
which will send the errors to the "err" file. Take a look at that file
afterwards and see what is in it.
Basically, '2&>1" is almost never the right thing to do, unless you
explicitly don't care about the output and just want to suppress it.
So "2&>1 > /dev/null" is common and natural.
Of course, people also use it when they just want to eyeball the
errors mixed in, so doing that
... 2&>1 | less
thing isn't necessarily *wrong*, but it's somewhat dangerous and
confusing. Because when you do it you do need to be very aware of the
fact that the errors and output will be *mixed*. And the mixing will
not necessarily be at all sensible.
Finally: pipes on a low level guarantee certain atomicity constraints,
so if you do low-level "write()" calls of size PIPE_BUF or less, the
contents will not be interleaved randomly. HOWEVER. That's only true
at that "write()" level. The moment you use <stdio> for your IO, you
have buffering inside of the standard IO libraries, and if your code
isn't explicitly very careful about it, using setbuf() and fflush()
and friends, you'll get that random mixing.
Anyway. That was a long email just to tell people it's almost
certainly user error, not the kernel.
Linus
From: Mike Galbraith <hidden> Date: 2021-09-17 06:38:45
On Thu, 2021-09-16 at 17:49 +0200, Mike Galbraith wrote:
Both kernels failed to reproduce...
Nor did the TW kernel (now 5.14.2-1-default) reproduce, neither in my
Leap-15.3 box, nor in a TW KVM set up to play server. 'course that
doesn't mean there's no kernel bug lurking, means with certainty only
that if there is one, the posted reproducer ain't all that wonderful.
-Mike