Intermittent failure of t0021
- From
Michael Haggerty <mhagger@alum.mit.edu>
- Date
- Dec 27, 2016, 19:21 UTC
- Message-ID
- <ec454def-88a7-5562-1bfe-9d52de42dc55@alum.mit.edu>
Hi,
I'm seeing intermittent failures of t0021. If I run it as follows (using a ramdisk as temporary space, and `EXPENSIVE` turned off), it fails on average about every 40 attempts:
$ make -j8 O=0 && (cd t && for i in $(seq 200); do if ./t0021-*.sh ; then echo "passed attempt $i"; else echo "failed on attempt $i"; break; fi ; done )
(I've also seen it fail while running the whole test suite, so it is not the tight test loop that triggers the problem.)
The output when it fails is
Initialized empty Git repository in /home/mhagger/self/proj/git/git/t/trash directory.t0021-conversion/repo/.git/ [master (root-commit) 56d459b] test commit 1 Author: A U Thor <author@example.com> 1 file changed, 1 insertion(+) create mode 100644 .gitattributes [master c30c7fc] test commit 2 Author: A U Thor <author@example.com> 4 files changed, 5 insertions(+) create mode 100644 test.r create mode 100644 test2.r create mode 100644 test4-empty.r create mode 100644 testsubdir/test3 'sq',$x.r sort: cannot read: rot13-filter.log: No such file or directory --- expected.log 2016-12-27 17:58:18.017505012 +0000 +++ rot13-filter.log 2016-12-27 17:58:18.017505012 +0000
@@ -1,7 +0,0 @@ -x IN: clean test.r 57 [OK] -- OUT: 57 . [OK] -x IN: clean test2.r 14 [OK] -- OUT: 14 . [OK] -x IN: clean test4-empty.r 0 [OK] -- OUT: 0 [OK] -x IN: clean testsubdir/test3 'sq',$x.r 49 [OK] -- OUT: 49 . [OK] - 1 START - 1 STOP - 1 init handshake complete not ok 15 - required process filter should filter data The failure bisects to 9c48b4f "t0021: minor filter process test cleanup", 2016-12-04 If I test the two parts of that commit separately, it is the removal of the `.` arguments from `git commit` that triggers the failures (i.e., not the removal of the creation of `.gitignore`). It's possible that the test was unreliable or racy even before this change, but I have run the same test 1000+ times against the parent commit (b18f6a00662524443cfb82f5fed7d3b54524c8ab) under the same conditions without seeing a single failure. So *something* seems to have been changed for the worse by this commit. I don't plan to look into it any further, but if you have trouble reproducing the problem don't hesitate to contact me. Michael