RE: [ANNOUNCE] Git v2.21.0-rc1 (NonStop Results) - Good News

RE: [ANNOUNCE] Git v2.21.0-rc1 (NonStop Results) - Good News

[Randall S. Becker]

On February 16, 2019 3:27, Max Kirillov wrote:
> On Fri, Feb 15, 2019 at 04:13:15PM -0500, Randall S. Becker wrote:
> > Sadly, the fix does not change the results. In fact, it makes the hang
> > far more likely. Subtest 6,7,8 fails here, at close()
> 
> Correct, I did not expect it to help, it was for the other issue.
> 
> As for the hang issue, from your another message it seems to me that perl
> waiting correctly, there are really child process which do not exit.
> 
> What you could try is
> https://public-inbox.org/git/20181124093719.10705-1-max@max630.net/
> (I'm not sure it would not conflict by now), this would remove dependency
> between tests. If it helps it would be very valuable information.

Good news. This patch does seem to do the trick. I wonder whether this fixes
the Azure build also.

I have run the test under the following conditions:
Run 1 (system idle): Pass
Run 2 (system idle): Pass
Run 3 (system idle): Pass
Run 4 (system idle): Pass
Run 5 (system idle): Pass
Run 6 (system mild load, heavy file system): Pass
Run 7 (system mild load, moderate file system load - git fetch): Pass
Run 8 (heavy system load, heavy file system load): Pass
Run 9 (--verbose, heavy system load, heavy file system load): Pass
Run 10 (GIT_TRACE=true, --verbose, heavy system load, heavy file system
load): Pass
Run 11 (very heavy system load, very heavy file system load): Pass

The current condition of the code is (the generate_zero_bytes delete was
previously removed so can be ignored for the patch):

diff --git a/t/t5562-http-backend-content-length.sh
b/t/t5562-http-backend-content-length.sh
index bbadde2c6e..f0f425b2cf 100755
--- a/t/t5562-http-backend-content-length.sh
+++ b/t/t5562-http-backend-content-length.sh
@@ -8,12 +8,12 @@ test_lazy_prereq GZIP 'gzip --version'
 verify_http_result() {
        # some fatal errors still produce status 200
        # so check if there is the error message
-       if grep 'fatal:' act.err
+       if grep 'fatal:' act.err.$test_count
        then
                return 1
        fi

-       if ! grep "Status" act.out >act
+       if ! grep "Status" act.out.$test_count >act
        then
                printf "Status: 200 OK\r\n" >act
        fi
@@ -33,7 +33,7 @@ test_http_env() {
                REQUEST_METHOD=POST \
                "$PERL_PATH" \
                "$TEST_DIRECTORY"/t5562/invoke-with-content-length.pl \
-                   "$request_body" git http-backend >act.out 2>act.err
+                   "$request_body" git http-backend >act.out.$test_count
2>act.err.$test_count
 }

 ssize_b100dots() {
@@ -143,14 +143,14 @@ test_expect_success GZIP 'push gzipped empty' '

 test_expect_success 'CONTENT_LENGTH overflow ssite_t' '
        NOT_FIT_IN_SSIZE=$(ssize_b100dots) &&
-       generate_zero_bytes infinity  | env \
+       env \
                CONTENT_TYPE=application/x-git-upload-pack-request \
                QUERY_STRING=/repo.git/git-upload-pack \
                PATH_TRANSLATED="$PWD"/.git/git-upload-pack \
                GIT_HTTP_EXPORT_ALL=TRUE \
                REQUEST_METHOD=POST \
                CONTENT_LENGTH="$NOT_FIT_IN_SSIZE" \
-               git http-backend >/dev/null 2>err &&
+               git http-backend </dev/null >/dev/null 2>err &&
        grep "fatal:.*CONTENT_LENGTH" err
 '

@@ -161,7 +161,7 @@ test_expect_success 'empty CONTENT_LENGTH' '
                GIT_HTTP_EXPORT_ALL=TRUE \
                REQUEST_METHOD=GET \
                CONTENT_LENGTH="" \
-               git http-backend <empty_body >act.out 2>act.err &&
+               git http-backend <empty_body >act.out.$test_count
2>act.err.$test_count &&
        verify_http_result "200 OK"
 '

RE: [ANNOUNCE] Git v2.21.0-rc1 (NonStop Results) - Good News

[Randall S. Becker]

On February 16, 2019 11:51, I wrote:
> To: 'Max Kirillov' <max@max630.net>
> Cc: 'SZEDER Gábor' <szeder.dev@gmail.com>; 'Johannes Schindelin'
> <Johannes.Schindelin@gmx.de>; 'Junio C Hamano' <gitster@pobox.com>;
> git@vger.kernel.org
> Subject: RE: [ANNOUNCE] Git v2.21.0-rc1 (NonStop Results) - Good News
> 
> On February 16, 2019 3:27, Max Kirillov wrote:
> > On Fri, Feb 15, 2019 at 04:13:15PM -0500, Randall S. Becker wrote:
> > > Sadly, the fix does not change the results. In fact, it makes the
> > > hang far more likely. Subtest 6,7,8 fails here, at close()
> >
> > Correct, I did not expect it to help, it was for the other issue.
> >
> > As for the hang issue, from your another message it seems to me that
> > perl waiting correctly, there are really child process which do not
exit.
> >
> > What you could try is
> > https://public-inbox.org/git/20181124093719.10705-1-max@max630.net/
> > (I'm not sure it would not conflict by now), this would remove
> > dependency between tests. If it helps it would be very valuable
> information.
> 
> Good news. This patch does seem to do the trick. I wonder whether this
fixes
> the Azure build also.

And apologies for the stupid wrapping done by my mail client when I pasted
the diff in. The patch is available from the link above anyway so you don't
need the junk from my mailer anyway.

Cheers,
Randall

Re: [ANNOUNCE] Git v2.21.0-rc1 (NonStop Results) - Good News

[Junio C Hamano]

"Randall S. Becker" <rsbecker@nexbridge.com> writes:

> On February 16, 2019 3:27, Max Kirillov wrote:
>
>> What you could try is
>> https://public-inbox.org/git/20181124093719.10705-1-max@max630.net/
>> (I'm not sure it would not conflict by now), this would remove dependency
>> between tests. If it helps it would be very valuable information.
>
> Good news. This patch does seem to do the trick. I wonder whether this fixes
> the Azure build also.
>
> I have run the test under the following conditions:
> Run 1 (system idle): Pass
> Run 2 (system idle): Pass
> Run 3 (system idle): Pass
> Run 4 (system idle): Pass
> Run 5 (system idle): Pass
> Run 6 (system mild load, heavy file system): Pass
> Run 7 (system mild load, moderate file system load - git fetch): Pass
> Run 8 (heavy system load, heavy file system load): Pass
> Run 9 (--verbose, heavy system load, heavy file system load): Pass
> Run 10 (GIT_TRACE=true, --verbose, heavy system load, heavy file system
> load): Pass
> Run 11 (very heavy system load, very heavy file system load): Pass

That indeed is a good news.

> The current condition of the code is (the generate_zero_bytes delete was
> previously removed so can be ignored for the patch):

Just to make sure I do not misunderstand, this result is with Max's
patch but without the generate_zero_bytes stuff?

Thanks, all.  Hopefully we can get this test failures behind us
before -rc2; knock, knock...

RE: [ANNOUNCE] Git v2.21.0-rc1 (NonStop Results) - Good News

[Randall S. Becker]

On February 16, 2019 13:06, Junio C Hamano wrote:
> "Randall S. Becker" <rsbecker@nexbridge.com> writes:
> > On February 16, 2019 3:27, Max Kirillov wrote:
> >> What you could try is
> >> https://public-inbox.org/git/20181124093719.10705-1-
> max@max630.net/
> >> (I'm not sure it would not conflict by now), this would remove
> >> dependency between tests. If it helps it would be very valuable
> information.
> >
> > Good news. This patch does seem to do the trick. I wonder whether this
> > fixes the Azure build also.
> >
> > I have run the test under the following conditions:
> > Run 1 (system idle): Pass
> > Run 2 (system idle): Pass
> > Run 3 (system idle): Pass
> > Run 4 (system idle): Pass
> > Run 5 (system idle): Pass
> > Run 6 (system mild load, heavy file system): Pass Run 7 (system mild
> > load, moderate file system load - git fetch): Pass Run 8 (heavy system
> > load, heavy file system load): Pass Run 9 (--verbose, heavy system
> > load, heavy file system load): Pass Run 10 (GIT_TRACE=true, --verbose,
> > heavy system load, heavy file system
> > load): Pass
> > Run 11 (very heavy system load, very heavy file system load): Pass
> 
> That indeed is a good news.
> 
> > The current condition of the code is (the generate_zero_bytes delete
> > was previously removed so can be ignored for the patch):
> 
> Just to make sure I do not misunderstand, this result is with Max's patch but
> without the generate_zero_bytes stuff?

Correct.

> Thanks, all.  Hopefully we can get this test failures behind us before -rc2;
> knock, knock...

Once the fix is integrated and in the usual spots, I can verify with haste. The full test cycle is now at 50 hours (argh), which I will rerun in full at rc2, but this one is fast.

Re: [ANNOUNCE] Git v2.21.0-rc1 (NonStop Results) - Good News

[Junio C Hamano]

"Randall S. Becker" <rsbecker@nexbridge.com> writes:

>> > The current condition of the code is (the generate_zero_bytes delete
>> > was previously removed so can be ignored for the patch):
>> 
>> Just to make sure I do not misunderstand, this result is with Max's patch but
>> without the generate_zero_bytes stuff?
>
> Correct.

Thanks for a quick response.  I've been staring at b46221ff ("Merge
branch 'rb/no-dev-zero-in-test'", 2019-02-13).  IIUC, t5562 wouldn't
have passed if it still fed http-backend from /dev/zero, no?  The
shell redirection would have failed, so we do need to keep that part
of the change---i.e. in order to pass, we do need cc95bc20 ("t5562:
replace /dev/zero with a pipe from generate_zero_bytes", 2019-02-09)
and Max's "t5562: do not reuse output files", right?

I have been wondering about the whole /dev/zero business.  Although
we have b46221ff ("Merge branch 'rb/no-dev-zero-in-test'",
2019-02-13) in 'master', "git grep /dev/zero t" has hits in
t/helper/test-sha1.sh and t/t4152-am-resume-override-opts.sh, so it
must have been somewhat incomplete to help platforms that lack
/dev/zero in the first place.

We haven't heard from Dscho in European timezone, but I'm
inclined to

 - keep b46221ff in 'master', not reverted.
 - apply Max's "t5562: do not reuse output files"

to 'master' and hope that we can declare victory in this part of the
code ;-).  There may be fix-ups for other topics before -rc2 on top
of that, though.

>> Thanks, all.  Hopefully we can get this test failures behind us before -rc2;
>> knock, knock...
>
> Once the fix is integrated and in the usual spots, I can verify
> with haste. The full test cycle is now at 50 hours (argh), which I
> will rerun in full at rc2, but this one is fast.

Re: [ANNOUNCE] Git v2.21.0-rc1 (NonStop Results) - Good News

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> I have been wondering about the whole /dev/zero business.  Although
> we have b46221ff ("Merge branch 'rb/no-dev-zero-in-test'",
> 2019-02-13) in 'master', "git grep /dev/zero t" has hits in
> t/helper/test-sha1.sh and t/t4152-am-resume-override-opts.sh, so it
> must have been somewhat incomplete to help platforms that lack
> /dev/zero in the first place.
>
> We haven't heard from Dscho in European timezone, but I'm
> inclined to
>
>  - keep b46221ff in 'master', not reverted.
>  - apply Max's "t5562: do not reuse output files"
>
> to 'master' and hope that we can declare victory in this part of the
> code ;-).  There may be fix-ups for other topics before -rc2 on top
> of that, though.

Just to make sure you didn't miss the exchange, the above plan is
still the latest ("Max's patch is [1]).  As I'll be offline most of
the day today, you still have time to stop or make me change course
to avoid disaster by interjecting (which would be very much
appreciated).

Thanks.


[Reference]

*1* https://public-inbox.org/git/20181124093719.10705-1-max@max630.net/

RE: [ANNOUNCE] Git v2.21.0-rc1 (NonStop Results) - Good News

[Randall S. Becker]

On February 18, 2019 13:46, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
> 
> > I have been wondering about the whole /dev/zero business.  Although we
> > have b46221ff ("Merge branch 'rb/no-dev-zero-in-test'",
> > 2019-02-13) in 'master', "git grep /dev/zero t" has hits in
> > t/helper/test-sha1.sh and t/t4152-am-resume-override-opts.sh, so it
> > must have been somewhat incomplete to help platforms that lack
> > /dev/zero in the first place.
> >
> > We haven't heard from Dscho in European timezone, but I'm inclined to
> >
> >  - keep b46221ff in 'master', not reverted.
> >  - apply Max's "t5562: do not reuse output files"
> >
> > to 'master' and hope that we can declare victory in this part of the
> > code ;-).  There may be fix-ups for other topics before -rc2 on top of
> > that, though.
> 
> Just to make sure you didn't miss the exchange, the above plan is still the
> latest ("Max's patch is [1]).  As I'll be offline most of the day today, you still
> have time to stop or make me change course to avoid disaster by interjecting
> (which would be very much appreciated).

No interjection expected. That is what I have been testing, so anticipate that this is correct.

Re: [ANNOUNCE] Git v2.21.0-rc1 (NonStop Results) - Good News

[Johannes Schindelin]

Hi Junio,

On Sat, 16 Feb 2019, Junio C Hamano wrote:

> "Randall S. Becker" <rsbecker@nexbridge.com> writes:
> 
> >> > The current condition of the code is (the generate_zero_bytes delete
> >> > was previously removed so can be ignored for the patch):
> >> 
> >> Just to make sure I do not misunderstand, this result is with Max's patch but
> >> without the generate_zero_bytes stuff?
> >
> > Correct.
> 
> Thanks for a quick response.  I've been staring at b46221ff ("Merge
> branch 'rb/no-dev-zero-in-test'", 2019-02-13).  IIUC, t5562 wouldn't
> have passed if it still fed http-backend from /dev/zero, no?  The
> shell redirection would have failed, so we do need to keep that part
> of the change---i.e. in order to pass, we do need cc95bc20 ("t5562:
> replace /dev/zero with a pipe from generate_zero_bytes", 2019-02-09)
> and Max's "t5562: do not reuse output files", right?
> 
> I have been wondering about the whole /dev/zero business.  Although
> we have b46221ff ("Merge branch 'rb/no-dev-zero-in-test'",
> 2019-02-13) in 'master', "git grep /dev/zero t" has hits in
> t/helper/test-sha1.sh and t/t4152-am-resume-override-opts.sh, so it
> must have been somewhat incomplete to help platforms that lack
> /dev/zero in the first place.
> 
> We haven't heard from Dscho in European timezone,

Some bacteria redirected me to /dev/zero for a few days. That hung my
inbox.

> but I'm inclined to
> 
>  - keep b46221ff in 'master', not reverted.
>  - apply Max's "t5562: do not reuse output files"
> 
> to 'master' and hope that we can declare victory in this part of the
> code ;-).  There may be fix-ups for other topics before -rc2 on top
> of that, though.

For the record, I did not set up that fully automated PR build & test at
https://github.com/gitgitgadget/git just so people would still wait for me
to run the test; a simple PR would have tested this without waiting for
me.

Anyway, in the meantime, I tested it, and Max' test seems to work:

https://dev.azure.com/git-for-windows/git/_build/results?buildId=31274

Ciao,
Dscho

> >> Thanks, all.  Hopefully we can get this test failures behind us before -rc2;
> >> knock, knock...
> >
> > Once the fix is integrated and in the usual spots, I can verify
> > with haste. The full test cycle is now at 50 hours (argh), which I
> > will rerun in full at rc2, but this one is fast.
> 

Re: [ANNOUNCE] Git v2.21.0-rc1 (NonStop Results) - Good News

[Max Kirillov]

On Sat, Feb 16, 2019 at 10:57:52AM -0800, Junio C Hamano wrote:
> I'm inclined to
> 
>  - keep b46221ff in 'master', not reverted.

from the branch, cc95bc2025 "t5562: replace /dev/zero with a
pipe from generate_zero_bytes" could be replaced with [1]
"t5562: do not depend on /dev/zero", for simplicity. I
cannot however test the issue as I have no access to the
platform in question. As far as I understand, both should
work.

[1] https://public-inbox.org/git/20190215164237.12250-1-max@max630.net/

RE: [ANNOUNCE] Git v2.21.0-rc1 (NonStop Results) - Good News

[Randall S. Becker]

On February 18, 2019 15:25, Max Kirillov wrote:
> On Sat, Feb 16, 2019 at 10:57:52AM -0800, Junio C Hamano wrote:
> > I'm inclined to
> >
> >  - keep b46221ff in 'master', not reverted.
> 
> from the branch, cc95bc2025 "t5562: replace /dev/zero with a pipe from
> generate_zero_bytes" could be replaced with [1]
> "t5562: do not depend on /dev/zero", for simplicity. I cannot however test
> the issue as I have no access to the platform in question. As far as I
> understand, both should work.
> 
> [1] https://public-inbox.org/git/20190215164237.12250-1-
> max@max630.net/

AFAIK, b46221ff and [1] should be included. I have no preference on the
title. As soon as (dT based $DAYJOB and $SLEEP) the merge is available (or
-rc2) comes out, I will test t5562 then run a full regression on NonStop and
report back. t5562 takes under a minute. The full suite is 50 hours. How's
that?

Cheers,
Randall

Re: [ANNOUNCE] Git v2.21.0-rc1 (NonStop Results) - Good News

[Johannes Schindelin]

Hi,

On Mon, 18 Feb 2019, Johannes Schindelin wrote:

> On Sat, 16 Feb 2019, Junio C Hamano wrote:
> 
> > [...] but I'm inclined to
> > 
> >  - keep b46221ff in 'master', not reverted.
> >  - apply Max's "t5562: do not reuse output files"
> > 
> > to 'master' and hope that we can declare victory in this part of the
> > code ;-).  There may be fix-ups for other topics before -rc2 on top
> > of that, though.
> 
> [...] in the meantime, I tested it, and Max' test seems to work:
> 
> https://dev.azure.com/git-for-windows/git/_build/results?buildId=31274

I have to take that assessment back. So sad.

After that build, I cherry-picked the commit on top of shears/pu (which is
Git for Windows' ever-green branch that continuously rebases Git for
Windows' `master` onto git.git's `pu`), and the build seems to hang again:

https://dev.azure.com/git-for-windows/git/_build/results?buildId=31291

I kicked off another build with Max' patch reverted, and my `test-tool
genzeros` patch applied on top:

https://dev.azure.com/git-for-windows/git/_build/results?buildId=31293

I won't be able to wait for its outcome before logging off for the night
(read: feel free to check its progress yourself, if the linux-clang job is
still running 10 minutes after I send this mail, it is probably safe to
assume that it hangs, otherwise it is fine), but I am fairly certain that
it will work around the issue again, as it did exactly that before in
several tests (and also in v2.21.0-rc1.windows.1).

Ciao,
Dscho

RE: [ANNOUNCE] Git v2.21.0-rc1 (NonStop Results) - Good News

[Johannes Schindelin]

Hi,

On Mon, 18 Feb 2019, Randall S. Becker wrote:

> On February 18, 2019 13:46, Junio C Hamano wrote:
> > Junio C Hamano <gitster@pobox.com> writes:
> > 
> > > I have been wondering about the whole /dev/zero business.  Although we
> > > have b46221ff ("Merge branch 'rb/no-dev-zero-in-test'",
> > > 2019-02-13) in 'master', "git grep /dev/zero t" has hits in
> > > t/helper/test-sha1.sh and t/t4152-am-resume-override-opts.sh, so it
> > > must have been somewhat incomplete to help platforms that lack
> > > /dev/zero in the first place.
> > >
> > > We haven't heard from Dscho in European timezone, but I'm inclined to
> > >
> > >  - keep b46221ff in 'master', not reverted.
> > >  - apply Max's "t5562: do not reuse output files"
> > >
> > > to 'master' and hope that we can declare victory in this part of the
> > > code ;-).  There may be fix-ups for other topics before -rc2 on top of
> > > that, though.
> > 
> > Just to make sure you didn't miss the exchange, the above plan is still the
> > latest ("Max's patch is [1]).  As I'll be offline most of the day today, you still
> > have time to stop or make me change course to avoid disaster by interjecting
> > (which would be very much appreciated).
> 
> No interjection expected. That is what I have been testing, so anticipate that this is correct.

As I wrote in nycvar.QRO.7.76.6.1902182249140.45@tvgsbejvaqbjf.bet, Max'
patch did not actually fix the hang on the Linux agents.

So unfortunately this plan won't work,
Johannes

Re: [ANNOUNCE] Git v2.21.0-rc1 (NonStop Results) - Good News

[Max Kirillov]

On Mon, Feb 18, 2019 at 10:57:13PM +0100, Johannes Schindelin wrote:
> I have to take that assessment back. So sad.
> 
> After that build, I cherry-picked the commit on top of shears/pu (which is
> Git for Windows' ever-green branch that continuously rebases Git for
> Windows' `master` onto git.git's `pu`), and the build seems to hang again:
> 
> https://dev.azure.com/git-for-windows/git/_build/results?buildId=31291

Hi.

You seem to be talking about the hang like it's some old
thing, I probably have missed some earlier discussion. I
have not heard before that it hangs on linux. The 60 seconds
hang because of lost SIGCHILD is not it. Also the hang
observed at NonStop is not it as well since the no-reuse
hack did not help (though numbered output files probably
would be more sure to avoid duplications expecially at
Windows where you cannot just unlink busy file and reuse its
place in directory)

From the tasks you have posted there seem to be no details
available. The test is not reported as completed, and the
overall build fails, and there seem to no additional data
except the log available.

Have you or somebody else been investigating it or is there
otherwise any information about those hangs?

-- 
Max

Re: [ANNOUNCE] Git v2.21.0-rc1 (NonStop Results) - Good News

[Max Kirillov]

On Tue, Feb 19, 2019 at 10:15:36PM +0200, Max Kirillov wrote:
> expecially at
> Windows where you cannot just unlink busy file and reuse its
> place in directory

It was at Linux actually. Well, whatever the rename feels more
sure thing to me.

RE: [ANNOUNCE] Git v2.21.0-rc1 (NonStop Results) - Good News

[Randall S. Becker]

On February 19, 2019 15:16, Max Kirillov <max@max630.net> wrote:
> On Mon, Feb 18, 2019 at 10:57:13PM +0100, Johannes Schindelin wrote:
> > I have to take that assessment back. So sad.
> >
> > After that build, I cherry-picked the commit on top of shears/pu
> > (which is Git for Windows' ever-green branch that continuously rebases
> > Git for Windows' `master` onto git.git's `pu`), and the build seems to
hang
> again:
> >
> > https://dev.azure.com/git-for-windows/git/_build/results?buildId=31291
> 
> Hi.
> 
> You seem to be talking about the hang like it's some old thing, I probably
> have missed some earlier discussion. I have not heard before that it hangs
on
> linux. The 60 seconds hang because of lost SIGCHILD is not it. Also the
hang
> observed at NonStop is not it as well since the no-reuse hack did not help
> (though numbered output files probably would be more sure to avoid
> duplications expecially at Windows where you cannot just unlink busy file
and
> reuse its place in directory)
> 
> >From the tasks you have posted there seem to be no details
> available. The test is not reported as completed, and the overall build
fails,
> and there seem to no additional data except the log available.
> 
> Have you or somebody else been investigating it or is there otherwise any
> information about those hangs?

The no-reuse hack made a big different
(https://public-inbox.org/git/20181124093719.10705-1-max@max630.net/) in
conjunction with replacing </dev/zero with </dev/null. It was the sleep
hack, and generate_zero_bytes that had no effect. I previously supplied a
multi-run result. Please refer to that fix/test for reference, which I paste
below:

On February 16, 2019 13:06, Junio C Hamano wrote:
> "Randall S. Becker" <rsbecker@nexbridge.com> writes:
> > On February 16, 2019 3:27, Max Kirillov wrote:
> >> What you could try is
> >> https://public-inbox.org/git/20181124093719.10705-1-
> max@max630.net/
> >> (I'm not sure it would not conflict by now), this would remove 
> >> dependency between tests. If it helps it would be very valuable
> information.
> >
> > Good news. This patch does seem to do the trick. I wonder whether 
> > this fixes the Azure build also.
> >
> > I have run the test under the following conditions:
> > Run 1 (system idle): Pass
> > Run 2 (system idle): Pass
> > Run 3 (system idle): Pass
> > Run 4 (system idle): Pass
> > Run 5 (system idle): Pass
> > Run 6 (system mild load, heavy file system): Pass Run 7 (system mild 
> > load, moderate file system load - git fetch): Pass Run 8 (heavy 
> > system load, heavy file system load): Pass Run 9 (--verbose, heavy 
> > system load, heavy file system load): Pass Run 10 (GIT_TRACE=true, 
> > --verbose, heavy system load, heavy file system
> > load): Pass
> > Run 11 (very heavy system load, very heavy file system load): Pass
> 
> That indeed is a good news.
> 
> > The current condition of the code is (the generate_zero_bytes delete 
> > was previously removed so can be ignored for the patch):
> 
> Just to make sure I do not misunderstand, this result is with Max's 
> patch but without the generate_zero_bytes stuff?

Correct.

Re: [ANNOUNCE] Git v2.21.0-rc1 (NonStop Results) - Good News

[Johannes Schindelin]

Hi Max,

On Tue, 19 Feb 2019, Max Kirillov wrote:

> On Mon, Feb 18, 2019 at 10:57:13PM +0100, Johannes Schindelin wrote:
> > I have to take that assessment back. So sad.
> > 
> > After that build, I cherry-picked the commit on top of shears/pu (which is
> > Git for Windows' ever-green branch that continuously rebases Git for
> > Windows' `master` onto git.git's `pu`), and the build seems to hang again:
> > 
> > https://dev.azure.com/git-for-windows/git/_build/results?buildId=31291
> 
> Hi.
> 
> You seem to be talking about the hang like it's some old
> thing, I probably have missed some earlier discussion. I
> have not heard before that it hangs on linux. The 60 seconds
> hang because of lost SIGCHILD is not it. Also the hang
> observed at NonStop is not it as well since the no-reuse
> hack did not help (though numbered output files probably
> would be more sure to avoid duplications expecially at
> Windows where you cannot just unlink busy file and reuse its
> place in directory)
> 
> From the tasks you have posted there seem to be no details
> available. The test is not reported as completed, and the
> overall build fails, and there seem to no additional data
> except the log available.
> 
> Have you or somebody else been investigating it or is there
> otherwise any information about those hangs?

Sorry, there has been so much talk about "hang", and we got quite a bit of
things mixed up.

What I was talking about, in the text you quoted, we an infinite hang in
t5562.15 on Linux (but I could not reproduce locally, it only happened in
the CI, but there it happened *reliably*). All the builds timed out after
60 *minutes*.

This has thankfully been addressed in the meantime, so "my" hang is gone.

Thanks,
Dscho

P.S.: in some other thread, I was picking up on something you said about
that hang that *you* were talking about, the one timing out after 60
seconds. I did not observe that here, but I had hoped (in vain) that a
quick read over the code would turn up something useful (which was my
suggestion to close stdout in the gzip case, but it seemed to not make a
difference).