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

["Randall S. Becker" <rsbecker@nexbridge.com>]

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.