Description of problem: kde crash on start Version-Release number of selected component (if applicable): kdelibs-4.3.0-7.fc12.i686 How reproducible: 100% Steps to Reproduce: 1. boot in runlevel 5 2. choice KDE 3. login Actual results: Message like 'Could not start kdeinit4. Check your installation' Expected results: KDE start and run Additional info: export LC_ALL=C; export LANG=C; startx > kde.error.log 2>&1 tail kde.error.log ... 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. tail /var/log/messages ... Aug 25 20:40:25 rawhide kernel: kdeinit4[5066]: 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. /usr/bin/startkde -LD_BIND_NOW=true kdeinit4 +kcminit_startup +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. prelink -ua 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] output 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 math/s_fmaf.os 0000000000000030 0000001100000009 R_X86_64_GOTPCREL 0000000000000010 __fmaf_sse2 - 4 0000000000000038 0000001000000009 R_X86_64_GOTPCREL 0000000000000000 __fmaf_fma - 4 math/s_fma.os 0000000000000030 0000001100000009 R_X86_64_GOTPCREL 0000000000000010 __fma_sse2 - 4 0000000000000038 0000001000000009 R_X86_64_GOTPCREL 0000000000000000 __fma_fma - 4 string/strcasestr-c.os 0000000000000018 0000001500000009 R_X86_64_GOTPCREL 0000000000000c20 __strcasestr_sse2 - 4 0000000000000020 0000001600000009 R_X86_64_GOTPCREL 0000000000000000 __strcasestr_sse42 - 4 string/strstr-c.os 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. ***
Fixed.
*** Bug 521976 has been marked as a duplicate of this bug. ***