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

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Feb 20, 2019, 20:15 UTC
Message-ID: <nycvar.QRO.7.76.6.1902202112420.41@tvgsbejvaqbjf.bet>
In-Reply-To: <20190219201536.GA2354@jessie.local>

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).