Re: What's cooking in git.git (Nov 2016, #06; Mon, 28)

From: Jeff King <peff@peff.net>
Date: Nov 29, 2016, 06:37 UTC
Message-ID: <20161129063759.6mgmpqx3kbyuqjwi@sigill.intra.peff.net>
In-Reply-To: <20161129010538.GA121643@google.com>

On Mon, Nov 28, 2016 at 05:05:38PM -0800, Brandon Williams wrote:

Show 15 quoted lines

> 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