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
(0x00007f903c1e8000)
libc.so.6 => /lib64/libc.so.6 (0x00007f903be40000)
libkonsoleprivate.so => /usr/lib64/libkonsoleprivate.so
(0x00007f903bb30000)
libknotifyconfig.so.4 => /usr/lib64/libknotifyconfig.so.4
(0x00007f903b918000)
/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
loadable!
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