Version: 3.2-rc (using KDE 3.2.0 RC1, compiled sources) Compiler: gcc version 3.3.3 20031229 (prerelease) (Debian) OS: Linux (i686) release 2.6.1 The whole of kde locks up for me since I'm trying the -rc. -beta1, -beta2 didn't lock up. I don't know what causes this or triggers it. Sometimes the keyboard locks up too, and just the mouse can be moved. In that case, I can ssh into my machine and do a 'killall -KILL kdeinit' and get to the x term and restart kde. The apps I'm using are: konqueror, kopete, kmail/kontact, kwallet, kget, kalarm, klipper, konsole. The time it takes to trigger too is indeterministic. 'ps' doesn't show anything interesting either. Tell me if you want more info...
I am seeing this behaviour too (dunno if it is actuallu same bug, but here goes): After upgrading from 3.1.5 to 3.2.1 (Debian Sid), KDE sometimes (several times a day) (temporarily) freezes/locks up. Keyboard is completely 'dead', but I can still move the mouse around (cannot clock anything, though). If I remain patient enough, however, KDE suddenly reponds again (sometimes it takes as much as 30-60 seconds). I see no disk activity nor high CPU load (this is monitored with an ssh login session from another host). I have absolutely *no* idea what this temporarily desktop freeze relates to. I see no pattern whatsoever. It can happen just browsing a web page with Konqueror, or writing an email in Kmail, or doing anything else. I see the bug on two different systems, btw. On both systems I have even tried moving my old ~/.kde (and ~/.kderc) out of the way to get a clean/fresh KDE environment for my user - but to no effect, I'm afraid.
On Tuesday 23 Mar 2004 19:11, Frederik Dannemare wrote: > After upgrading from 3.1.5 to 3.2.1 (Debian Sid), KDE sometimes (several > times a day) (temporarily) freezes/locks up. Keyboard is completely 'dead', > but I can still move the mouse around (cannot clock anything, though). similar symptoms... > If I remain patient enough, however, KDE suddenly reponds again (sometimes > it takes as much as 30-60 seconds). I see no disk activity nor high CPU > load (this is monitored with an ssh login session from another host). but this doesn't happen. No matter how long I wait, it doesn't come back. It freezes for good for me.
sounds like a mouse/keyboard grab gone wrong, does alt-tab do anything?
Darn it. I just had a total freeze with both keyboard and mouse being dead. I expected that KDE would come back from the dead (like I've seen it happen before), but this time I waited for 20 minutes until I gave up and rebooted. The last thing I did just before the freeze happened was exiting Noatun (but I really don't think Noatun itself directly had anything to do with the freeze). This is really bad and I would certainly consider it a critical bug. I suspect that only a total rebuild of KDE with debugging enabled can help me/us in finding the source of this problem? Or is there anything else I/we can do in an attempt to narrow down the possible reasons for this freeze to occur?
>>sounds like a mouse/keyboard grab gone wrong, does alt-tab do anything? ctrl-alt-f1 and ctrl-alt-backspace didn't work for me, so I just considered the keyboard be to 100% dead. Didn't try alt-tab, though. Do you really think alt-tab would work when the other two does not? Well, I'll at least give it a try when the next freeze comes by.
On Thursday 25 Mar 2004 19:53, Frederik Dannemare wrote: > This is really bad and I would certainly consider it a critical bug. I > suspect that only a total rebuild of KDE with debugging enabled can help > me/us in finding the source of this problem? Or is there anything else I/we Even with the debug symbols compiled in, how can we get any useful info? The desktop's just locked, so we can't get any symbols for any app, and we can't also access the console to which debug messages are output.
I was thinking of running all apps from konsoles and then make sure that another windows would never overlap the konsoles. This way I was hoping to see just a little bit of output in a konsole when the freeze happens. Don't know if that is a bit too much to wish for? Other than this I cannot think of a way to grab any valuable output. Waldo Bastian, do you have any suggestions for debugging this problem? Would Valgrind be of any use in any way (have never tried Valgrind, so I don't really know a whole lot about it)? Or can output from KDE (and KDE apps) somehow be continuously collected in a central lof file of some kind? I'm not really a veteran debugger, as you can hear.
If you can login via ssh, you can try to kill processes one by one and see if that brings it back to life. Try to see if there is one particular process that brings things back to life. The most likely suspects are klipper, kicker, kdesktop and kwin. Which Qt version do you use? Which package number?
According to my Qt Debian packages currently installed, I am using Qt version 3.2.3 (newest available version in Debian Sid). pkgs: libqt3-headers 3.2.3-2 Qt3 header files libqt3c102-mt 3.2.3-2 Qt GUI Library (Threaded runtime version)
Had a total freeze yesterday just before I went to bed. I was too tired to investigate, so I let it stay frozen throughout the night. Then this morning I tried ssh'ing into the machine from another host, but without any luck. It didn't respond to anything via the network, so I concluded that the machine was totally dead and rebooted. All systems logs (syslog, messages, kern.log, daemon.log, etc) stopped reporting just around the very time when I experienced (that I thought was) a KDE freeze. I guess at least my problems reported here stick deeper than KDE, so I'm sorry for the noise it may have caused. I guess I'll go look for kernel oops and such (and do a kernel upgrade very soon). I'm still experiencing short/temporarily desktop freezes once in a while, though (when I come to think of it, Konqueror is always running (either in the background, or because I'm using it actively)). This odd behavior has been reported in bug #77916.
I'm having the same symptoms. My freeze-ups happen when I try to click on the an app in the taskbar. Alt-tab works to switch apps and unfreeze KDE, unless I'm trying to switch to an app on another desktop, which cannot be done.
I have the same exact symptoms. I've found that one workaround is to keep hitting the alt, shift, and control keys on both sides of the keyboard repeatedly, and eventually KDE will start responding again. This whole bug seems to be a problem with the kicker application, since after it happens, my kicker becomes pretty much unusable. I've seen this since KDE 3.2.0. After I get control of my system again, I kill the kicker app (ps auxw|grep kicker, and kill the kicker kdeinit process), and restart kicker. Sometimes I have to "killall -9 kicker" :( It would be SO TOTALLY BODACIOUSLY AWESOME IF THIS BUG COULD BE FIXED. I'm willing to help out as much as I can, especially since my desktop locks up probably 8 or 9 times a DAY! It's fine because I can recover from it, but it's pretty annoying. I've also found that separating the main KDE toolbar from the taskbar helps this from happening as much. I'm running RedHat 9, with all of the rpms that are distributed with KDE 3.2.1. I haven't tried 3.2.2, but I doubt it will help since it wasn't listed in the changelog.
By the way, I'm also running kernel 2.6.5. I think this problem may also be related to the kernel version that's being used, unfortunately. I don't recall having this ever happen with kernel 2.4.x, but I still think that KDE should be able to work around the problem (if there is one) in kernel 2.6.x.
I've seen this problem, as described in comment 11 and comment 12, on a Fedora Core 1 system upgraded to kde-3.2.1. As FC1 has kernel 2.4, I don't believe it to be kernel-related. I believe I was able to minimize the problem by changing the size of the panel and disabling the panel auto-hide, but this is not conclusive. Since upgrading to kdebase-3.2.3, I have not been able to reproduce.
In fact, isn't this a duplicate of bug 74487 ?
*** This bug has been confirmed by popular vote. ***
Hello all. Same problem here, but with a diference: if I have a terminal open, just use the mouse to click the terminal and move it a little, the keyboard starts to work again. I am using Debian stable, with just kde 3.3.1 from unstable, and a kernel 2.6.9. The freezes usually occurs when I am typing a text in a box in konqueror or even Firefox, or any form. Just lock up! Them, move the open terminal around and the keyboard starts to work again. I am using transparency in my terminal also (konsole), but i don't think that this is the problem.
Sorry! "Debian stable" should be "Debian testing"!!!
Ivan: Do you have klipper running in the system tray? Does it help if you remove it?
Hello all. After I stopped using klipper, the problem vanished, but now klipper doesn't work anymore, just got segmentation fault. After that, Knotes started to give me some problems, locking up all the keyboard. Killing Knotes was not enough, I had to kill Knotes and move the terminal to restore the keyboard. I am still using Debian testing 2.6.9 with kde 3.3.1. Changing XFree86 to Xorg didn't change anything.
Anyone still experiencing this with recent KDE versions? I used to run into this bug too, but haven't seen it since 3.4, I'm surprised it's still open...
I haven't got it for ages either....
Seems nobody can reproduce anymore.
Still happening here, Qt: 3.3.4 KDE: 3.5.1 KDesktop: 3.5.1, kscd 1.6. Unable to get traceback or something useful for debug, thought.