On Mon, Nov 28, 2016 at 05:05:38PM -0800, Brandon Williams wrote:
> On 11/28, Junio C Hamano wrote:
> > * bw/grep-recurse-submodules (2016-11-22) 6 commits
> > - grep: search history of moved submodules
> > - grep: enable recurse-submodules to work on <tree> objects
> > - grep: optionally recurse into submodules
> > - grep: add submodules as a grep source type
> > - submodules: load gitmodules file from commit sha1
> > - submodules: add helper functions to determine presence of submodules
> >
> > "git grep" learns to optionally recurse into submodules
> >
> > Has anybody else seen t7814 being flakey with this series?
>
> Which tests in particular are you seeing issues with? I can't see any
> issues running it locally.
It looks like tests 14 and 15 are racy. The whole script usually passes,
but if I run it under my stress script[1], it fails within 5-10 seconds
on one of those two.
The failures always look like (this one is from test 15, but the one in
test 14 is similar):
--- expect 2016-11-29 06:26:37.874664486 +0000
+++ actual 2016-11-29 06:26:37.878664486 +0000
@@ -1,2 +1 @@
-file:foobar
sub-moved/file:foobar
I haven't dug into it, but I don't see anything obviously racy-looking
in the test, so presumably it's in the code. Without looking, but
knowing the nature of the code, I'd guess the probable avenues are:
1. A read() or write() that gets split under load (just because
there's processes piping to other processes here).
2. Grep threads doing more complicated stuff that needs to take a
lock. You might try building with -fsanitize=thread to see if it
turns up anything.
-Peff
[1] https://github.com/peff/git/blob/meta/stress