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 <tbo...@web.de>
> 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),
> ls -l crlf*.err
> give you any hint ?
No. It simply does not contain that warning that is expected.