All versions of kde3. KDE starts up okay, then every second a new crash window for knotify appears. Within minutes the system becomes unusable because of large memory use. Kdesktop also seems not to be functioning. gcc 3.2-r1. I've tried recompiling world yet problem persists. My usual cflags are -march=pentium3 -O3 -pipe -mmmx -msse -mfpmath=sse -fomit-frame-pointer. I have also tried recompiling the whole of kde with no cflags. Same problem appears. Also kde applications like konqueror function within kde, but crash when run from other DE's or WM's.
sorry what I meant to say at the end is that konqueror crashes in file manager mode also.
me too! kde 3.0.3 , gcc 3.2 CFLAGS="-march=i586 -m3dnow -O2 -pipe" (processor is via C3 ezra) running startkde via X11 tunnelling through ssh from windows 2000 with cygwin/XFree86. kde basically seems to work ok apart from continuous knotify crashes. here's some of the output from startkde... (all these lines get repeated for each crash of knotify) Xlib: extension "XInputExtension" missing on display "localhost:10.0". Failed to get list of devices mcop warning: user defined signal handler found for SIG_PIPE, overriding KCrash: crashing.... crashRecursionCounter = 2 KCrash: Application Name = knotify path = <unknown> pid = 5063 DCOP aborting call from 'anonymous-5062' to 'knotify' ERROR: KUniqueApplication: DCOP communication error!
Roy: so maybe that missing XInputExtension is to blame? Maybe knotify requires it or at least expects it to exist because it's compiled against xfree and not against the x server you're using on your windows machine, if i understood you correctly. Try configuring your x server to provide it, or using some different x server just to test if it works. Try running kde locally from the machine it's installed on to see if it works with xfree. Dan: are you also using a remote x server by any chance?
I've had the same problem since upgrading to 1.4 rc1. I've tried both kde 3.03 and kdecvs. My gcc flags are highly optimized but since others have had the same probs and at least one person on the forum had tried a very basic build with normal flags I doubt this is the issue. Mark
Upgrading a system to a new gcc versiob never seems to work out ok... :-( Why don't you just build a new one in a chroot and copy your /etc and homedirs over? :-)
Rebuilding from scratch is an option but it would be a shame since everything but kde seems fine. Admittedly I did build from scratch for gcc3.11 previously with no probs. The thing is I'm not 100 per cent sure that gcc is the problem. There is always a chance something was upgraded during the process and thats the problem. I will take the advice I'm given though if nobody has any other ideas I'll give it a go Mark
Okay I had a change of heart. Rebuilding now. I'll let everyone know how it went Mark
Just wanted to add everyone who complained about this to cc: so that people can try the various things suggested here. If this problem is fixed for one of you, please tell us :-)
Dan, I've tried again with a local xserver rather than the remote one. I don't get the XInputExtension message anymore, but I still get the knotify crashes. I'm thinking it may be related to sound. If I run artsd on it's own it seg faults. There is a sound chip on this computer, but there is no kernel driver or module configured for it. (this is a via epia 800) Roy
Okay, I only have qt, kdelibs and kdebase at the moment on my freshly installed 1.4-rc1 system, but kde is starting without problem. So Dan was probably right. Looks like the upgade to 3.2 was the problem. Mark
artsd also seems to crash for me. I've rebuilt world with -e and it didn't fix the problems.
I now have reinstalled 1.4 rc1 afresh as Dan suggested. I used kde-cvs but I Was having the problem with both cvs and 3.03 so this shouldnt matter. I am no longer getting the knotify crash. Anyone who has the knotify crash who used the scripts to upgrade. I suggest you bite the bullet and install affresh coying over your old /etc and /home dir's. It worked for me Mark
no fn way. It's absolutely unreasonable that you have to reinstall gentoo every time gcc or kde changes. Obviously it's something wrong with the portage system. It could be because portage doesn't manage cfg files? Or an ebuild somewhere along the line borked? Don't know. But I'm not biting any bullets. No way I'm waiting the 4 or 5 days it's going to take to recompile my whole system. I mean, openoffice takes 12 hours alone. Either kde will start working or I'll keep using gnome2, which I've grown quite accustomed to now.
sorry I was a little heated :P What I really meant to say, is that since it's not a huge problem, maybe theres a much simpler workaround than reinstalling the entire distro. Not only that, but if we find the problem, it can be avoided next time we upgrade gcc, or kde.
Well, I'm not saying there isn't a fix other than reinstalling your whole system. Basically what I meant was that compiling in the background quietly, say over nights, you could have built a new system several times over since this bug was submitted. But of course there are ways to fix your existing system; only I'm not the right person to ask. In other words if all these problems for all of you are caused by gcc upgrading issues, then this shouldn't be assigned to kde@gentoo.org (since I can't help you, I don't know much of anything about gcc upgrading after the point where it goes bad). Did _everyone_ here upgrade their gcc or does someone (Roy?) have this problem on a new system?
hmm, I've tried that. emerge -e world. The problem wasn't fixed.
I _did_ upgrade from a 1.2 system with gcc 2.95 to gcc 3.2, but I did not emerge X11, kde or arts until after the upgrade. Does everyone else think this is just down artsd? I have now configured my sound driver and I can play sound properly with XMMS (not using arts), however I still get the problem with artd segfaulting. I have tried recompiling arts with no optimisation at all, but still get the segfault. I haven't had much time to do more investigation. Roy
Can someone who has reinstalled 1.4 from scratch please post the output of the following couple of commands ls -l /usr/lib/libstdc++* ldd `which artsd` here's mine... fillerbunny lib # ls -l /usr/lib/libstdc++* -rwxr-xr-x 1 root root 271052 Sep 19 14:54 /usr/lib/libstdc++-libc6.1-1.so.2 -rw-r--r-- 1 root root 6626734 Jul 22 00:03 /usr/lib/libstdc++.a -rw-r--r-- 1 root root 1050 Jul 22 00:03 /usr/lib/libstdc++.la lrwxrwxrwx 1 root root 18 Jul 22 00:03 /usr/lib/libstdc++.so -> libstdc++.so.4.0.0 lrwxrwxrwx 1 root root 20 Sep 19 14:54 /usr/lib/libstdc++.so.2.7.2 -> libstdc++.so.2.7.2.8 -rwxr-xr-x 1 root root 226168 Sep 19 14:54 /usr/lib/libstdc++.so.2.7.2.8 lrwxrwxrwx 1 root root 18 Sep 19 14:54 /usr/lib/libstdc++.so.2.8 -> libstdc++.so.2.8.0 -rwxr-xr-x 1 root root 255728 Sep 19 14:54 /usr/lib/libstdc++.so.2.8.0 lrwxrwxrwx 1 root root 18 Jul 22 00:03 /usr/lib/libstdc++.so.4 -> libstdc++.so.4.0.0 -rwxr-xr-x 1 root root 805260 Jul 22 00:03 /usr/lib/libstdc++.so.4.0.0 fillerbunny lib # ldd `which artsd` libsoundserver_idl.so.1 => /usr/kde/3/lib/libsoundserver_idl.so.1 (0x40015000) libkmedia2_idl.so.1 => /usr/kde/3/lib/libkmedia2_idl.so.1 (0x4006c000) libartsflow.so.1 => /usr/kde/3/lib/libartsflow.so.1 (0x400ab000) libartsflow_idl.so.1 => /usr/kde/3/lib/libartsflow_idl.so.1 (0x401aa000) libaudiofile.so.0 => /usr/lib/libaudiofile.so.0 (0x40247000) libasound.so.2 => /usr/lib/libasound.so.2 (0x4026a000) libmcop_mt.so.1 => /usr/kde/3/lib/libmcop_mt.so.1 (0x402e2000) libmcop.so.1 => /usr/kde/3/lib/libmcop.so.1 (0x402e7000) libresolv.so.2 => /lib/libresolv.so.2 (0x40394000) libdl.so.2 => /lib/libdl.so.2 (0x403a5000) libpthread.so.0 => /lib/libpthread.so.0 (0x403a8000) libstdc++.so.4 => /usr/lib/libstdc++.so.4 (0x403bd000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x40487000) libstdc++.so.5 => /usr/lib/gcc-lib/i586-pc-linux-gnu/3.2/libstdc++.so.5 (0x40490000) libm.so.6 => /lib/libm.so.6 (0x4055e000) libc.so.6 => /lib/libc.so.6 (0x40581000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) The reason for all this is that artsd is linking against /usr/lib/libstdc++.so.4, which appears to have been compiled with gcc 2.95 (I'm going by the dates on the files - July 11th was before I upgraded to gcc 3.2, Sept 19th must have been when I upgraded. libstdc++.so.4.0.0 doesn't seem to have been rebuilt with the gcc upgrade. I'm intrigued to know whether you get a libstdc++.so.4 at all from a fresh install of gentoo. Not sure whether it's related to artsd at all, but it's attracted my interest... roy
i have gentoo-1.4 from scratch, here's my output: hannes@neptun ~ $ ls -l /usr/lib/libstdc++* -rwxr-xr-x 1 root root 271052 Sep 6 15:52 /usr/lib/libstdc++-libc6.1-1.so.2 lrwxrwxrwx 1 root root 20 Sep 6 15:52 /usr/lib/libstdc++.so.2.7.2 -> libstdc++.so.2.7.2.8 -rwxr-xr-x 1 root root 226168 Sep 6 15:52 /usr/lib/libstdc++.so.2.7.2.8 lrwxrwxrwx 1 root root 18 Sep 6 15:52 /usr/lib/libstdc++.so.2.8 -> libstdc++.so.2.8.0 -rwxr-xr-x 1 root root 255728 Sep 6 15:52 /usr/lib/libstdc++.so.2.8.0 hannes@neptun ~ $ ldd `which artsd` libsoundserver_idl.so.1 => /usr/kde/cvs/lib/libsoundserver_idl.so.1 (0x4 0017000) libkmedia2_idl.so.1 => /usr/kde/cvs/lib/libkmedia2_idl.so.1 (0x4007d000) libartsflow.so.1 => /usr/kde/cvs/lib/libartsflow.so.1 (0x400c2000) libartsflow_idl.so.1 => /usr/kde/cvs/lib/libartsflow_idl.so.1 (0x4021000 0) libaudiofile.so.0 => /usr/lib/libaudiofile.so.0 (0x402e3000) libvorbisfile.so.3 => /usr/lib/libvorbisfile.so.3 (0x4030c000) libvorbisenc.so.2 => /usr/lib/libvorbisenc.so.2 (0x40313000) libvorbis.so.0 => /usr/lib/libvorbis.so.0 (0x403fc000) libogg.so.0 => /usr/lib/libogg.so.0 (0x4041c000) libmad.so.0 => /usr/lib/libmad.so.0 (0x40420000) libmcop_mt.so.1 => /usr/kde/cvs/lib/libmcop_mt.so.1 (0x40438000) libmcop.so.1 => /usr/kde/cvs/lib/libmcop.so.1 (0x4043d000) libstdc++.so.5 => /usr/lib/gcc-lib/i686-pc-linux-gnu/3.2/libstdc++.so.5 (0x404f8000) libdl.so.2 => /lib/libdl.so.2 (0x405c2000) libpthread.so.0 => /lib/libpthread.so.0 (0x405c5000) libgcc_s.so.1 => /usr/lib/gcc-lib/i686-pc-linux-gnu/3.2/libgcc_s.so.1 (0 x405dc000) libm.so.6 => /lib/libm.so.6 (0x405e4000) libc.so.6 => /lib/libc.so.6 (0x40607000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
Force QT recompilation. It resolve that pb on my work's box. Still a pb with knotify, so, like I'm not at work next week, I've launched a emerge -e kde.
Thanks for that output Hannes. My conclusion is that this is definitly a gcc upgrade issue. Even though I did not emerge kde until after I had upgraded to gcc 3.2, the kde binaries were linking to an old gcc 2.95 libstdc++, which was causing the segfaults. The problem was inside some locale function in libstdc++ according to a stack trace from the core file. I've discovered that gcc 2.95 had not been removed properly, since the upgrade scripts I used did an "emerge -c gcc-2.95", but it was still protected. I've now done an "emerge -C gcc-2.95" which forces a clean and also made sure that the old libraries in /usr/lib have been removed. I'm in the process of re-emerging everything that links against the old c++ lib (all of kde, galeon, a few other things) - I basically did an ldd on everything in /usr and then used qpkg -f on the files that came up with "not found" on a library to find the package. I'm happy for this bug to be closed. dan - if you don't want to reinstall from scratch, try removing gcc-2.95 with emerge -C or just moving out the libstdc++.so.4 files from /usr/lib to somewhere safe and "emerge -e --nodeps" artsd and kdemultimedia. You might need to do kde-libs too, I can't really remember. You may then get away with moving the libs back to /usr/lib, but it might be better to purge them completely and rebuild all c++ programs. thanks everyone! Roy
dan, you're the only one left with problems. Please let us know how it goes.
sure, I will do an 'emerge qt', If it persists, emerge -e kde. If it still persists, emerge -e world. Just a couple of notes: I started with gcc 3.0.1 I think, never had 2.9x on my gentoo box. I've done emerge -e world and it didn't fix the problem before so let's see if it will this time, if not i'll build with debug info and look a bit closer. I'm not the only one with the problem though, I had a thread on the DE forum on gentoo.org which got resurected by a few people recently. Thanks everyone for helping. I will post the results of the attempted fix.
I've got the same pb on my box at work. Ever tryed to compile QT, and the, entire kde. Unsolved pb.
I Just got KDE emerged, and I ran smack into this problem as well. AS soon as I started up KDE, many, many crashes. While is was crashing, I managed to pull off a "killall -9 drkonqi" in a shell window which wiped out any built up crashes. From my perspective, it was this "drkonqi" program that is segfaulting. A Fix I managed to do was to simply "mv /usr/kde/3/bin/drkonqi /usr/kde/3/bin/drkonqi_____old" to get the program out of the way. KDE Starts up fine now. I have NO idea what "drkonqi" is atm, but it doesn't appear to be a super-important system file or program. Some stats on my system is below. Originally Gentoo 1.4_beta, using GCC 3.1, Followed upgrade script procedures to migrate to GCC 3.2. All uneccessary packages were unmerged BEFORE starting the upgrade procedure. This included KDE, QT, arts, X, and many others. By the time I was done, I was at a pure console system, with "links" for a web browser and "irssi" for an IRC client. Then I ran all the scripts to rebuild the system. Some generic system stats: Linux barad-dur.drachentekh.net 2.4.19-xfs #1 SMP Thu Oct 10 19:32:49 EDT 2002 i686 Pentium III (Coppermine) GenuineIntel GNU/Linux 2xPentium III; 832MB Ram; 60GB IBM Harddrive; A-Bit VP6 Mobo w/ Via 694X Northbridge/686B Southbridge. If anyone has any ideas, please post. Should I discover anything more, I'll re-post as well.
Joshua: drkonqi is the KDE Crash Handler :-) It's the window that oppens with the bomb image and the display-traceback option. I'm sorry, but it seems that gcc updates fail more often than not. You could, and IMHO should, have build a new system with gcc 3.2 in much the same time it took you to upgrade your old one. Copy over your /etc, /home etc. and you're set to go. Of course you may not want to do that again now, but it's the only sure fix _I_ know about. I haven't looked much into the sources of this problem because it really is the gcc guys' business (i.e. the Gentoo gcc guys).
I've got this pb only on one of my gentoos. I've three gentoo box (and two debian, hehe). I've migrated all my gentoos to gcc 3.2 and made an emerge -e world. All have the same USE and C/XXFLAGS. KDE don't work only on this box. Very strange... I actually running gnome (doh!) because of this pb. I really want to come back to KDE. I'll try to paste errors messages on a file and then send you this file, hope this help....
Created attachment 5204 [details] Error messages displayed on launcher console Here are the error message. P
Created attachment 5204 [details] Error messages displayed on launcher console Here are the error message. Périphérique ou ressource occupé = peripherial in use or busy. anonymous-xxxx = kdeinit:knotify or drkonqi -display I've actualy renamed knotify & drkonqi to use KDE. It's working, but the system is slow and unstable. Some strange behaviour, like random menu popups, nothing showed when I move a window, etc... Can I do more to hepl ?
Just a little correction : P
Just a little correction : Périphérique ou ressource occupé = peripherial or resource busy
ok I'm out of the running since I gave up and reinstalled. :P I realized I wasn't doing enough "emerge clean" commands. Maybe that could be it? Thanks for all the help.
I've found the source of the problem, it's arts. I've first tryed to change version (1.0.4 <-> 1.1.0), but the cresh boxes are still popup ever and ever. I've tryed to disable artsd loading (in sound preferences), same pb. Finnally, I've made a emerge -C arts, and.... IT'S WORKING !!! Don't know why arts is doing that. Can I give you more information to help you to debug ?
seems noone has left any problems, or am I wrong? psk: have you tracked down your arts problem?
It's seems it came from dcopidl binary. Don't now more.
Should this bug be closed now? I'll close it if there's not more protests.
closing bug because it has resolved itself. It was a transition bug.
