Red Hat Bugzilla – Bug 519226
LD_BIND_NOW=true (in /usr/bin/startkde) => badness
Last modified: 2009-09-08 18:30:52 EDT
Description of problem:
kde crash on start
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. boot in runlevel 5
2. choice KDE
Message like 'Could not start kdeinit4. Check your installation'
KDE start and run
export LC_ALL=C; export LANG=C; startx > kde.error.log 2>&1
startkde: Starting up...
/usr/bin/startkde: line 321: 5528 Segmentation fault LD_BIND_NOW=true kdeinit4 +kcminit_startup
startkde: Could not start kdeinit4. Check your installation.
Aug 25 20:40:25 rawhide kernel: kdeinit4: segfault at 803a0 ip 000803a0 sp bfc2132c error 14 in libkdecore.so.5.3.0[110000+275000]
Probably linked with bug #515539 and/or bug #519081 (more likely the latter)
yes, delete "LD_BIND_NOW=true" before "+kdeinit4 +kcminit_startup" help. KDE do not crash.
-LD_BIND_NOW=true kdeinit4 +kcminit_startup
*** Bug 519719 has been marked as a duplicate of this bug. ***
So reading bz515539, running 'prelink -f /usr/bin/kdeinit4' solved all my segfault problems on login.
>> 'prelink -f /usr/bin/kdeinit4'
prelink is not necessary and I do do not use it on desktop.
rpm -e prelink
OK, let's consider this the canonical
LD_BIND_NOW=true in /usr/bin/startkde => badness
bug, and volley to glibc folks for assistance.
It looks like LD_BIND_NOW is causing an unrelocated address to be put in the PLT slot.
0x00007ffff3884d80 in strstr@plt () from /lib64/libglib-2.0.so.0
1: x/i $pc
0x7ffff3884d80 <strstr@plt>: jmpq *0x2d1832(%rip) # 0x7ffff3b565b8 <fflush+2954136>
(gdb) x/gx 0x7ffff3b565b8
0x7ffff3b565b8 <fflush+2954136>: 0x00000000000895f0
(gdb) p/a $__+0x7ffff4179000
$1 = 0x7ffff42025f0 <__strstr_sse2>
Can you reduce the test case to something not including the KDE monster? What's the dependency order? LD_DEBUG output etc.
Ulrich, not sure if this helps in any way, but a very easy way to trigger this is doing this:
$ LD_BIND_NOW=1 /usr/libexec/pulse/gconf-helper
(Needs pulseaudio-module-gconf installed which is installed by default)
The gconf-helper tool is pretty simple, however still pulls in glib, gconf, orbit.
*** Bug 516671 has been marked as a duplicate of this bug. ***
Ulrich, it seems every application crashes with LD_BIND_NOW=1 on x86_64 with latest rawhide. I tried several times with LD_BIND_NOW=1 ls and got the segmentation fault. It doesn't crash by 1. time, you have to try several times to get it.
Created attachment 359474 [details]
the debug output
Looking at it, it is quite obvious what's wrong.
Out of the current IFUNC defining objects in glibc:
for i in */*.os; do case $i in elf/ifuncmod*) continue;; esac; \
readelf -Ws $i 2>/dev/null | grep -q IFUNC \
&& readelf -Wr $i | grep -q GOTPCREL && echo $i \
&& readelf -Wr $i | grep GOTPCREL; done
0000000000000030 0000001100000009 R_X86_64_GOTPCREL 0000000000000010 __fmaf_sse2 - 4
0000000000000038 0000001000000009 R_X86_64_GOTPCREL 0000000000000000 __fmaf_fma - 4
0000000000000030 0000001100000009 R_X86_64_GOTPCREL 0000000000000010 __fma_sse2 - 4
0000000000000038 0000001000000009 R_X86_64_GOTPCREL 0000000000000000 __fma_fma - 4
0000000000000018 0000001500000009 R_X86_64_GOTPCREL 0000000000000c20 __strcasestr_sse2 - 4
0000000000000020 0000001600000009 R_X86_64_GOTPCREL 0000000000000000 __strcasestr_sse42 - 4
0000000000000118 0000001500000009 R_X86_64_GOTPCREL 0000000000000540 __strstr_sse2 - 4
0000000000000120 0000001600000009 R_X86_64_GOTPCREL 0000000000000000 __strstr_sse42 - 4
As IFUNC relocations aren't ordered before other relocations, it is possible a call to indirect function is done before the target library has relative relocations resolved. I think just adding hidden attributes should cure this.
That said, I still wonder how fma/fmaf can work reliably, when it calls into a different DSO and the PLT slot is likely not initialized etc.
*** Bug 520973 has been marked as a duplicate of this bug. ***
Should be fixed upstream. Andreas will hopefully build a new version tomorrow.
Ulrich, i tried "LD_BIND_NOW=1 ls" on i386 machine today, it crashes too. It could be the same problem like on x86_64
The files are shared so it automagically receives the same fix.
Fixed in 2.10.90-20.
The most important file is not shared :-(
i even tested the 2.10.90-20, it still crashes on i386 machine
I fixed x86 as well.
Perhaps irrelevant at this point, but Bug 520973 was marked as a dup of this bug, and this bug was originally reported as KDE related. Bug 520973 was on a Gnome desktop, x86_64 system.
glibc-2_10_90-21 now fixes this issue for me. Thanks
*** Bug 515539 has been marked as a duplicate of this bug. ***
*** Bug 521509 has been marked as a duplicate of this bug. ***
*** Bug 521976 has been marked as a duplicate of this bug. ***