KDE apps crash

Duncan 1i5t5.duncan at cox.net
Wed Sep 11 11:46:44 BST 2013

P NIKOLIC posted on Wed, 11 Sep 2013 08:44:16 +0100 as excerpted:

> On Wed, 11 Sep 2013 08:32:55 +0100 P NIKOLIC <p.nikolic1 at btinternet.com>
> wrote:
>> Hi .
>> I have recently updated KDE to 4.11.1 on Arch Linux    .
>> Prior to the update almost everything worked fine now  almost every KDE
>> application i attempt to run crashes instantly  including the Kcrash
>> handler ..  below are just some of the reports .

>> Application: KPatience (kpat), signal: Segmentation fault

Snipping tracebacks...

>> Application: Kaffeine (kaffeine), signal: Segmentation fault

>> Application: Konqueror (konqueror), signal: Segmentation fault

>> all crash every time you try to start them that is just the few quick
>> ones but it happens to almost everything   ( gtk based apps not
>> effected )
> Hi and even the  System Settings  crash

> Application: System Settings (systemsettings), signal: Segmentation
> fault

> Getting silly now   .

Gentooer here.

Such crashes are very likely due to one of three things:  Either your 
user's kde config is screwed up, or you have an incompatible or missing 
library, likely due to bad dependencies in the binary package you 
installed, or if you compiled from source, probably due to one of the 
depended libs in turn needing an incompatible library, conflicting with 
the one kde itself was compiled against.  The third possibility, as 
reported by someone else on the list, is that for some reason the app 
can't contact your user dbus session, so make sure you have dbus running 
as your user (you may also have a system dbus running, I believe as root, 
tho I don't have one running here).

It's easy to rule out your user's kde config.  Try a clean config.  Your 
choice whether you do that by creating a new user and fresh home dir with 
which to test, or backup/delete or move your existing user's config 
(particularly the $KDEHOME dir, ~/.kde by default if $KDEHOME isn't set, 
altho some distros make that ~/.kde4 or similar), and try with the 
existing user but a clean config.

Assuming a clean user config doesn't fix the problem, the next thing to 
figure out is whether it's a qt library, a kde library, or something 
lower in the system but used by pretty much anything kde that whoever 
built that kde might have had a different version of, since you know that 
gtk apps aren't affected.

One simple and quick check is using ldd to check that all needed 
libraries can actually be found.  Here's the first few lines (plus one 
from slightly further in) of my output from ldd /usr/bin/konsole, here 
(amd64 system, x86 will be similar but a couple names will be different):

	linux-vdso.so.1 (0x00007fff4ffa0000)
	libkdeinit4_konsole.so => /usr/lib64/libkdeinit4_konsole.so 
	libc.so.6 => /lib64/libc.so.6 (0x00007f903be40000)
	libkonsoleprivate.so => /usr/lib64/libkonsoleprivate.so 
        libknotifyconfig.so.4 => /usr/lib64/libknotifyconfig.so.4 

        /lib64/ld-linux-x86-64.so.2 (0x00007f903c410000)

There's a general pattern with a couple of exceptions:

1) linux-vdso.so.1 is a "virtual" library actually provided by the 
kernel.  That's why it doesn't have the usual associated path.

2) /lib64/ld-linux-x86-64.so.2 has the full path as part of the library 
name, unlike the others which have the name without the path, then what 
path the library is actually resolving to.  This library is actually the 
loader used to find and load all the others, so its path must be hard-
coded as part of the executable itself, or NONE of the others will be 

As I said, if you're on 32-bit x86 (or some other arch), the names of 
those two might be slightly different, but they should be the same 
regardless of what executable you check, because those two libraries are 
loaded by pretty much any elf-file executable.

The thing you'd be looking for here is any OTHER libraries that don't 
list a path or the following hexadecimal checksum.  That'd be your 
missing library!  (I /believe/ it actually shows as MISSING, but am not 
going to double-check that ATM.)

A somewhat more thorough check would be using the -r switch as well.  The 
output should be about the same, but checks each data object and 
function, not just the library.

If that comes up clean, then it's time to dig a bit further.  Do you know 
if you have any non-kde qt4-only apps on your system?  SMPlayer (or 
smplayer2, is one I have here, and another one is the kernel's xconfig, 
invoked as make xconfig from within the kernel sources dir, tho the 
actual binary is scripts/kconfig/qconf (you can ldd it as well for a 
comparison, once it's created by the first make xconfig run).

(For xconfig, note that you'll need to run make xconfig once as a user 
with write permissions on the kernel sources to create the binary itself, 
which will then exist as scripts/kconfig/qconf.  That might mean running 
it as root.  However, unless you're logged in to your X session as root, 
which is discouraged, the actual qt4-based binary likely won't run as it 
won't have access to your X session.  But once the binary, again actually 
scripts/kconfig/qconf, is created as a user with write permissions, you 
will likely be able to run make xconfig as your normal X session user -- 
you just won't normall be able to save anything to the system dir.  But 
we're just seeing if it runs, not whether it can save anything.)

If a qt4-only app runs, then it's likely something wrong with kde itself, 
or one of its mostly kde-only non-qt deps such as strigi or nepomuk.  If 
a qt4-only app doesn't run, then it's likely a qt4 issue.

One reasonable possibility is that either you or the kde builder had 
upgraded qt4 since the kde that worked for you, but the version 
requirement wasn't strict enough in the deps required by the kde 
packages, so it didn't force you to match the same qt version, when it 
should have.

But of course it could be one of several other libraries also, including 
something wrong with one of the core kdelibs itself, or with strigi or 
something similar that virtually all kde apps load.  And that's assuming 
it's not your user config...

Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.

More information about the kde mailing list