KDE apps crash
P NIKOLIC
p.nikolic1 at btinternet.com
Thu Sep 12 08:33:22 BST 2013
On Wed, 11 Sep 2013 10:46:44 +0000 (UTC)
Duncan <1i5t5.duncan at cox.net> wrote:
> 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 .
Hi Duncan
If i have the internet bandwidth i might have had a look at Gentoo but i am Dongal
based so it makes it a non starter.
>
> 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.
>
Tied that one several times no go .
> 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!
Cant find any missing libs , everything seems to be ok
>
> 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).
Other that Firefox Claws-mail Gftp and Bluefish which i always use and have been
on every install for ages ,Everything else is native Arch Linux repo stuff all
64 bit .Oh and Barry Backup i believe it is a QT app for the Blackberry phone that
runs ok .
>
> (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.
Now i wonder if that is possible all that is turned off i dont use it at all , now
id it IS then the issue is how the *&^%^&** do you turn it back on when System
settings will not run and dies the same as everything else
>
> 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...
>
Pity it is not to easy to go back to the working version of KDE ..
Pete .
--
Linux 7-of-9 3.10.10-1-ARCH #1 SMP PREEMPT Fri Aug 30 11:30:06 CEST 2013 x86_64
GNU/Linux
___________________________________________________
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