Red Hat Bugzilla – Bug 252453
SIGSEGV during program startup
Last modified: 2007-11-30 17:12:13 EST
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): glibc-2.6.90-9 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: 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 libtest.so: libtest.c $(CC) -shared $(CFLAGS) -o $@ $^ clean: -rm -f libtest.so test *~ core* EOF cat > libtest.c <<\EOF #include <sys/time.h> #include <stdlib.h> void __attribute__((constructor)) foo (void) { struct timeval tv; gettimeofday (&tv, NULL); } EOF cat > test.c <<\EOF int main (void) { return 0; } 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 libpthread.so...
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 complaining. Thanks..