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
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