Re: general protection faults with "git grep" version 1.7.7.1

From: Thomas Rast <trast@student.ethz.ch>
Date: Oct 25, 2011, 16:54 UTC
Message-ID: <201110251854.43369.trast@student.ethz.ch>
In-Reply-To: <87sjmhauyo.fsf@rho.meyering.net>

Jim Meyering wrote:

Show 18 quoted lines

> Thomas Rast wrote:
> > Jim Meyering wrote:
> >> Thomas Rast wrote:
> >> > [GCC moves access to a file-static variable across pthread_mutex_lock()]
> >>
> >> Thanks for the investigation.
> >> Actually, isn't gcc -O2's code-motion justified?
> >> While we *know* that those globals may be modified asynchronously,
> >> builtin/grep.c forgot to tell gcc about that.
> >
> > I'm somewhat unwilling to believe that:
> 
> You're right to be skeptical.
> I should have stuck with "using volatile works around the problem for me".
> The real problem seems to be in glibc, with its addition of
> the "leaf" attribute to those synchronization primitives:
> 
>   http://bugzilla.redhat.com/747377#c22

Aha.  Glad you found it :-)

Meanwhile I read

  http://www.hpl.hp.com/techreports/2004/HPL-2004-209.html

which discusses a similar issue in section 4.3, but is very interesting on its own. It's funny how it says

  We know of at least three optimizing compilers (two of them
  production compilers) that performed this transformation at some
  point during their lifetime; usually at least partially reversing
  the decision when the implications on multi-threaded code became
  known.

I guess that would be four now if it was literally the same problem.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch