Bug 252453 - SIGSEGV during program startup
Summary: SIGSEGV during program startup
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: glibc   
(Show other bugs)
Version: rawhide
Hardware: x86_64 Linux
low
low
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
: 253240 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-08-16 03:56 UTC by Valdis Kletnieks
Modified: 2007-11-30 22:12 UTC (History)
2 users (show)

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: ---


Attachments (Terms of Use)

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..


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