On Wed, 11 Sep 2013 10:46:44 +0000 (UTC) Duncan <1i5t5.dun...@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.nikol...@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.
