On February 19, 2019 15:16, Max Kirillov <max@xxxxxxxxxx> 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@xxxxxxxxxx/) 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@xxxxxxxxxxxxx> writes: > > On February 16, 2019 3:27, Max Kirillov wrote: > >> What you could try is > >> https://public-inbox.org/git/20181124093719.10705-1- > max@xxxxxxxxxx/ > >> (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.
