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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
