Bug 252453 - SIGSEGV during program startup
SIGSEGV during program startup
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
rawhide
x86_64 Linux
low Severity low
: ---
: ---
Assigned To: Jakub Jelinek
Fedora Extras Quality Assurance
:
: 253240 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-08-15 23:56 EDT by Valdis Kletnieks
Modified: 2007-11-30 17:12 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-08-26 17:03:46 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Valdis Kletnieks 2007-08-15 23:56:32 EDT
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 03:18:20 EDT
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 08:42:12 EDT
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 09:10:45 EDT
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 03:00:34 EDT
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 11:09:56 EDT
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 11:37:43 EDT
*** Bug 253240 has been marked as a duplicate of this bug. ***
Comment 7 Jakub Jelinek 2007-08-26 17:03:46 EDT
Should be fixed in glibc-2.6.90-12 for real.
Comment 8 Valdis Kletnieks 2007-08-27 11:23:38 EDT
Confirming - I have -12 installed now, and my problematic binary isn't
complaining. Thanks..

Note You need to log in before you can comment on or make changes to this bug.