Bug 252453

Summary: SIGSEGV during program startup
Product: [Fedora] Fedora Reporter: Valdis Kletnieks <valdis.kletnieks>
Component: glibcAssignee: Jakub Jelinek <jakub>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: rawhideCC: drepper, tmraz
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-08-26 21:03:46 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Valdis Kletnieks 2007-08-16 03:56:32 UTC 
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.
Comment 1 Jakub Jelinek 2007-08-16 07:18:20 UTC 
That's vague, which existing binaries, linked dynamically or statically, can
you get a backtrace of the segfault?
Comment 2 Jakub Jelinek 2007-08-16 12:42:12 UTC 
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
Comment 3 Valdis Kletnieks 2007-08-16 13:10:45 UTC 
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..)
Comment 4 Jakub Jelinek 2007-08-17 07:00:34 UTC 
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...
Comment 5 Valdis Kletnieks 2007-08-17 15:09:56 UTC 
OK... My problem binary survives startup against 2.6.90-11, so leaving the bug
in 'assigned' is cool by me.
Comment 6 Jakub Jelinek 2007-08-17 15:37:43 UTC 
*** Bug 253240 has been marked as a duplicate of this bug. ***
Comment 7 Jakub Jelinek 2007-08-26 21:03:46 UTC 
Should be fixed in glibc-2.6.90-12 for real.
Comment 8 Valdis Kletnieks 2007-08-27 15:23:38 UTC 
Confirming - I have -12 installed now, and my problematic binary isn't
complaining. Thanks..