git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Brandon Williams <bmwill@google.com>
To: Jeff King <peff@peff.net>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: What's cooking in git.git (Nov 2016, #06; Mon, 28)
Date: Wed, 30 Nov 2016 15:28:23 -0800	[thread overview]
Message-ID: <20161130232823.GA192901@google.com> (raw)
In-Reply-To: <20161130195427.GA166433@google.com>

On 11/30, Brandon Williams wrote:
> On 11/29, Jeff King wrote:
> > 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
> 
> With you're stress script I'm able to see the failures.  The interesting
> thing is that the entry missing is always from the non-submodule file.

So I couldn't find a race condition in the code.  I tracked the problem
to grep_source_load_file which attempts to run lstat on the file so that
it can read it into a buffer.  The lstat call fails with ENOENT (which
conveniently is skipped by the if statement which calls error_errno).  So
for some reason the file cannot be found and read into memory resulting
in nothing being grep'ed for that particular file (since the buffer is
NULL).

Maybe there is something wrong with the way I wrote the tests
themselves?  So I could try rewriting them.  Any other ideas?

-- 
Brandon Williams

  reply	other threads:[~2016-11-30 23:28 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-29  0:15 What's cooking in git.git (Nov 2016, #06; Mon, 28) Junio C Hamano
2016-11-29  1:05 ` Brandon Williams
2016-11-29  6:37   ` Jeff King
2016-11-29  6:51     ` Jeff King
2016-11-30 19:54       ` Brandon Williams
2016-11-30 23:28         ` Brandon Williams [this message]
2016-11-30 23:32           ` Jeff King
2016-11-30 23:40             ` Jeff King
2016-11-30 23:42               ` Brandon Williams
2016-11-30 23:46                 ` Jeff King
2016-11-30 23:57                   ` Brandon Williams
2016-11-30 23:59                   ` Jeff King
2016-12-01  0:04                     ` Jeff King
2016-12-01  0:08                       ` Brandon Williams
2016-12-01  0:14                         ` Stefan Beller
2016-12-01  1:14                           ` Brandon Williams
2016-12-01  0:06                     ` Brandon Williams
2016-12-01  0:19                       ` Jeff King
2016-11-30 23:43               ` Stefan Beller
2016-12-01  7:09               ` Johannes Sixt
2016-12-01  7:19                 ` Jeff King
2016-11-29  6:59 ` Jeff King
2016-11-29 18:31   ` Junio C Hamano
2016-11-29 18:37     ` Jeff King
2016-11-29 19:21 ` Stefan Beller
2016-11-29 19:26   ` Junio C Hamano
2016-11-29 19:29     ` Stefan Beller
2016-11-30  0:25   ` Stefan Beller
2016-12-01  8:30 ` bw/transport-protocol-policy Jeff King
2016-12-01 18:14   ` bw/transport-protocol-policy Brandon Williams
2016-12-01 19:20     ` bw/transport-protocol-policy Jeff King
2016-12-01 19:35       ` bw/transport-protocol-policy Brandon Williams
2016-12-01 19:46         ` bw/transport-protocol-policy Jeff King
2016-12-01 19:53           ` bw/transport-protocol-policy Brandon Williams

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20161130232823.GA192901@google.com \
    --to=bmwill@google.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).