On Wed, 2011-10-19 at 20:51 +0200, Jim Meyering wrote:
I spent too many hours debugging this today, so feel obliged to warn
about this. Plus, I feel a little guilty for giving it positive
karma initially. Today's -1 was too late.
glibc-2.14.90-12.999, which has just made it to stable provokes a
hard-to-diagnose (for me at least) problem.
While most things work, and it fixed two problems that affected me,
it caused me some frustration:
TL;DR: while most things worked fine, and gcc even bootstrapped and
passed most of "make check" (I did that when I was wondering if I had
bad RAM), this version of glibc appears to make it so when you compile
git from cloned sources, the resulting git program evokes double frees,
arbitrary heap corruption, aborts, hangs, weird incomplete read errors,
etc. But only when you compile with -O2, not with -O1 or less.
Now, you might think that this is all git's fault, and maybe glibc is
merely exposing it. That may well be true. Until we find the underlying
cause we won't know for sure. However, I was surprised to see that
valgrind reported nothing, time after time, while glibc was obviously
detecting heap corruption.
To recover an F16 system that works better, I ran this:
yum downgrade glibc glibc-static glibc-devel glibc-common glibc-headers \
What did you downgrade to ?
AFAIK Several people had to downgrade from -11 because of nsswitch
issues ... seem glibc is not in good shape :-(
Simo Sorce * Red Hat, Inc * New York