threads / announce / 50526

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

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

## tl;dr

16 messages between Feb 16, 2019 and Feb 20, 2019.

replies: 15people: 4as markdown or json

Randall S. Becker· Feb 16, 2019, 16:51 UTC · lore
On February 16, 2019 3:27, Max Kirillov wrote:
Show 13 quoted lines
> 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"
 '
Randall S. Becker· Feb 16, 2019, 17:02 UTC · re: Randall S. Becker · lore
On February 16, 2019 11:51, I wrote:
Show 15 quoted lines
> 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.
Show 8 quoted lines
> >
> > 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

Junio C Hamano· Feb 16, 2019, 18:05 UTC · re: Randall S. Becker · lore

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

"Randall S. Becker" <rsbecker@nexbridge.com> writes:
Show 23 quoted lines
> 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...

Randall S. Becker· Feb 16, 2019, 18:24 UTC · re: Junio C Hamano · lore
On February 16, 2019 13:06, Junio C Hamano wrote:
Show 33 quoted lines
> "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.
Junio C Hamano· Feb 16, 2019, 18:57 UTC · re: Randall S. Becker · lore

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

"Randall S. Becker" <rsbecker@nexbridge.com> writes:
Show 7 quoted lines
>> > 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.

Show 6 quoted lines
>> 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.
Junio C Hamano· Feb 18, 2019, 18:45 UTC · re: Junio C Hamano · lore

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

Junio C Hamano <gitster@pobox.com> writes:
Show 16 quoted lines
> 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/
Randall S. Becker· Feb 18, 2019, 18:50 UTC · re: Junio C Hamano · lore
On February 18, 2019 13:46, Junio C Hamano wrote:
Show 22 quoted lines
> 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.
Johannes Schindelin· Feb 19, 2019, 10:05 UTC · re: Randall S. Becker · lore
Hi,
On Mon, 18 Feb 2019, Randall S. Becker wrote:
Show 25 quoted lines
> 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

Johannes Schindelin· Feb 18, 2019, 19:37 UTC · re: Junio C Hamano · lore

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

Hi Junio,
On Sat, 16 Feb 2019, Junio C Hamano wrote:
Show 26 quoted lines
> "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.

Show 8 quoted lines
> 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

Show 7 quoted lines
> >> 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.
> 
Johannes Schindelin· Feb 18, 2019, 21:57 UTC · re: Johannes Schindelin · lore

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

Hi,
On Mon, 18 Feb 2019, Johannes Schindelin wrote:
Show 14 quoted lines
> 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

Max Kirillov· Feb 19, 2019, 20:15 UTC · re: Johannes Schindelin · lore

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

On Mon, Feb 18, 2019 at 10:57:13PM +0100, Johannes Schindelin wrote:
Show 7 quoted lines
> 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
Max Kirillov· Feb 19, 2019, 20:36 UTC · re: Max Kirillov · lore

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

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.

Randall S. Becker· Feb 19, 2019, 20:53 UTC · re: Max Kirillov · lore
On February 19, 2019 15:16, Max Kirillov <max@max630.net> wrote:
Show 6 quoted lines
> 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
Show 8 quoted lines
> 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:
Show 33 quoted lines
> "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.
Johannes Schindelin· Feb 20, 2019, 20:15 UTC · re: Max Kirillov · lore

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

Hi Max,
On Tue, 19 Feb 2019, Max Kirillov wrote:
Show 28 quoted lines
> 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).

Max Kirillov· Feb 18, 2019, 20:24 UTC · re: Junio C Hamano · lore

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

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/
Randall S. Becker· Feb 18, 2019, 20:31 UTC · re: Max Kirillov · lore
On February 18, 2019 15:25, Max Kirillov wrote:
Show 13 quoted lines
> 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

← back to recent threads