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

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

On 11/28, Junio C Hamano wrote:

quoted

* 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