Description of problem:
Recent glibc update 2.6.90-9 breaks some existing binaries - they now SEGV
inside (reported) gettimeofday() before we even get to main(). (tested with gdb
- 'gdb binary', then doing a 'break main' and 'run', and it SEGV's before
hitting the breakpoint).
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Backing out glibc and glibc-common to -8 made the problem go away. My personal
bet is that the new vDSO code listed in the --changelog is to blame.
That's vague, which existing binaries, linked dynamically or statically, can
you get a backtrace of the segfault?
Seems the problem is when some DSO constructor uses gettimeofday before
libc.so has been initialized:
sed 's,^ ,\t,' > Makefile <<\EOF
CFLAGS += -O2 -fpic
test: test.c libtest.so
$(CC) $(CFLAGS) -o $@ $< -Wl,-rpath,. -L. -ltest
$(CC) -shared $(CFLAGS) -o $@ $^
-rm -f libtest.so test *~ core*
cat > libtest.c <<\EOF
struct timeval tv;
gettimeofday (&tv, NULL);
cat > test.c <<\EOF
Good thing you found it - I currently have 2.6.90-8 installed, and can't install
-9 to replicate it and get a traceback due to bug #252979, I need to track down
a backlevel rpm-libs rpm (and it's unclear how I'll bootstrap that install..)
Worked around in 2.6.90-11 by reverting temporarily gettimeofday.S changes.
Not closing this bug, since we don't have a proper fix yet.
With ptr mangling it is tricky - there is no way how to mangle a static
initializer, and checking at runtime whether the mangled pointer is NULL or not
is bad as well - in rare cases the initialized pointer can be mangled as 0.
We'd need to run some initialization routine of libc.so before all other lib
ctors, which is why we have DF_1_INITFIRST. But we already use that for
OK... My problem binary survives startup against 2.6.90-11, so leaving the bug
in 'assigned' is cool by me.
*** Bug 253240 has been marked as a duplicate of this bug. ***
Should be fixed in glibc-2.6.90-12 for real.
Confirming - I have -12 installed now, and my problematic binary isn't