BEWARE: a problematic glibc made it to stable (F16)

[Richard W.M. Jones]

On Mon, Oct 24, 2011 at 11:34:46PM +0200, Jim Meyering wrote:
> Jim Meyering wrote:
> > Adam Williamson wrote:
> >> ... The only breakage
> >> in one which was approved was to do with compiling things - which, sure,
> >> is a pain in the ass, but it's not the kind of problem critpath was
> >> introduced to deal with in the first place.
> >
> > The problem is bigger than it first seemed, and still not fixed.
> >
> > True, I noticed the problem initially when running a just-built git,
> > but in fact the distributed /usr/bin/git demonstrates precisely the
> > same heap corruption as the one I built.  See the further discussion
> > on http://bugzilla.redhat.com/747377
> >
> > The underlying bug seems pthread-related.
> > When I make git grep run without using threads there is no problem.
> >
> > To demonstrate the problem, run this on a multi-core system, in a
> > clone of a decent-sized git repository like git's own:
> >
> >     for i in $(seq 100);do echo $i; timeout 1 ./git grep -q stat;done
> 
> Oops.  Drop the "./", of course, to test /usr/bin/grep:

I think you mean /usr/libexec/git-core/git-grep :-)

I'm not convinced yet this is a glibc issue.  It could be a problem in
the threaded work-queue code in git-grep which is just exposed by the
change in glibc.  No one will know until we finally diagnose the bug.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora