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

[Jeff King <peff@peff.net>]

On Tue, Nov 29, 2016 at 01:37:59AM -0500, Jeff King wrote:

>   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.

I tried this and it didn't find anything useful. It complains about
multiple threads calling want_color() at the same time, which you can
silence with something like:

diff --git a/builtin/grep.c b/builtin/grep.c
index 2c727ef49..d48846f40 100644
--- a/builtin/grep.c
+++ b/builtin/grep.c
@@ -207,6 +207,12 @@ static void start_threads(struct grep_opt *opt)
 {
 	int i;
 
+	/*
+	 * trigger want_color() for its side effect of caching the result;
+	 * otherwise the threads will fight over setting the cache
+	 */
+	want_color(GIT_COLOR_AUTO);
+
 	pthread_mutex_init(&grep_mutex, NULL);
 	pthread_mutex_init(&grep_read_mutex, NULL);
 	pthread_mutex_init(&grep_attr_mutex, NULL);

But the problem persists even with that patch, so it is something else.
It may still be a threading problem; -fsanitize=thread isn't perfect. I
also couldn't get the stress-test to fail when compiled with it. But
that may simply mean that the timing of the resulting binary is changed
enough not to trigger the issue.

-Peff