Hi Torsten, On Mon, 8 Aug 2016, Torsten Bögershausen wrote: > On 2016-08-08 17.05, Johannes Schindelin wrote: > > > > I remember that you did a ton of work on t0027. Now I see problems, > > and not only that the entire script now takes a whopping 4 minutes 20 > > seconds to run on my high-end Windows machine. > > > > It appears that t0027 fails randomly for me, in seemingly random > > places. Sometimes all 1388 cases pass. Sometimes "29 - commit NNO > > files crlf=true attr=auto LF" fails. Sometimes it is "24 - commit NNO > > files crlf=false attr=auto LF". Sometimes it is "114 - commit NNO > > files crlf=false attr=auto LF", and sometimes "111 - commit NNO files > > attr=auto aeol=lf crlf=false CRLF_mix_LF". > > > > When I run it with -i -v -x --tee, it passes every single time (taking > > over 5 minutes, just to make things worse)... > > > > Any idea about any possible races? > > Just to double-check: I assume that you have this > commit ded2444ad8ab8128cae2b91b8efa57ea2dd8c7a5 > Author: Torsten Bögershausen <tboegi@xxxxxx> > Date: Mon Apr 25 18:56:27 2016 +0200 > > t0027: make commit_chk_wrnNNO() reliable > in your tree ? I tested this with multiple branches, but yes, the one I tested most was the shears/pu branch of git-for-windows/git (which has all Windows-specific patches of our master branch rebased on top of pu). I also tested with the pu branch as of yesterday. > Is there a special pattern ? No. Just "make -j15 DEVELOPER=1 -k test". > Did you > a) Update the machine ? Yep, it's up-to-date. Windows 10 Anniversary Update. > b) Update Git code base ? As I said, several. > Is it only the NNO tests that fail ? As I said, the failures are random, I just picked the 4 most recent ones. > Did they ever pass ? As I said, if I run with -i -v -x --tee, everything passes. > I see only "commit NNO files...." in you report, they belong to > check_warning(), which is called around line 126 in t0027. I believe this is true. Some race, probably, leading to the commit *not* refreshing the files. Or some such, this is just a guess on my side. > How reproducible is the problem ? Not very. That is, about half of the time t0027 passes even *without* -i -v -x --tee. And when it fails, it is anybody's guess which case fails. > If you add > exit 0 > After the last "commit_chk_wrnNNO" line (line 418), > does > ls -l crlf*.err > give you any hint ? No. It simply does not contain that warning that is expected. Ciao, Dscho