Version: 4.1.8x (using Devel) OS: Linux Installed from: Compiled sources While running downloads with kget I observed 100% CPU load by kded4. From kde3 I'm used to kill and just restart in such situations. So I sent the kded4 process a STOP signal. From that moment on the whole system did no longer respond to keyboard input and the mouse pointer disappeared. Switching to text console was not possible. Even login via ssh was no longer possible. Only ping was working. This is not exactly a crash
@Lukas: is this fault of kget?
Killing kded4 prevents global shortcuts from working (Alt+Tab etc.), but shouldn't prevent the mouse and normal keyboard operation from working. Anyway if kded uses 100% CPU, please attached gdb to it in order to provide a backtrace so that we can see what it's doing.
It happens not often but today kded4 again used 100% CPU (with a balance of about 60% system load and 40% user load). 1) Terminating kget did not change the situation. So probably this has nothing to do with kget. 2) Sending STOP signal to kded4 did _not_ hang the system. So "hangs the system" may be removed from the summary. 3) Attaching with gdb shows that and interrupting the kded4 several times shows that the CPU hog ist executing QEventDispatcherUNIXPrivate::doSelect(QFlags<QEventLoop::ProcessEventsFlag>, timeval*) () from /usr/lib/libQtCore.so.4 most the time. 3) Killing kded and restarting it brings the system back to normal activity. But functionality of e.g. Alt-Tab remains lost after restart. Here a typical backtrace (yes I have kdelibs4-debuginfo package installed, dunno why some calls are not resolved): #0 0xb63273da in clock_gettime () from /lib/librt.so.1 #1 0xb75fa7ab in ?? () from /usr/lib/libQtCore.so.4 #2 0xb75fa981 in ?? () from /usr/lib/libQtCore.so.4 #3 0xb75fafde in QEventDispatcherUNIXPrivate::doSelect(QFlags<QEventLoop::ProcessEventsFlag>, timeval*) () from /usr/lib/libQtCore.so.4 #4 0xb75fc661 in QEventDispatcherUNIX::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4 #5 0xb6add5e2 in ?? () from /usr/lib/libQtGui.so.4 #6 0xb75ccdea in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4 #7 0xb75cd22a in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4 #8 0xb75cf629 in QCoreApplication::exec() () from /usr/lib/libQtCore.so.4 #9 0xb6a3e777 in QApplication::exec() () from /usr/lib/libQtGui.so.4 #10 0xb7f8dcd6 in kdemain () from /usr/lib/libkdeinit4_kded4.so #11 0x08048722 in _start ()
I am having the same problem on OpenSUSE 11.1 using KDE 4.2 (4.2.0-70.4) from factory. Backtrace using system Qt 4.4.3:- 1. #0 0xb64fb3da in clock_gettime () from /lib/librt.so.1 2. #1 0xb7712beb in ?? () from /usr/lib/libQtCore.so.4 3. #2 0xb7712dc1 in ?? () from /usr/lib/libQtCore.so.4 4. #3 0xb771492d in ?? () from /usr/lib/libQtCore.so.4 5. #4 0xb7711060 in ?? () from /usr/lib/libQtCore.so.4 6. #5 0xb646a9a8 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 7. #6 0xb646e063 in ?? () from /usr/lib/libglib-2.0.so.0 8. #7 0xb646e221 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 9. #8 0xb7710fb8 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4 10. #9 0xb6cc57c5 in ?? () from /usr/lib/libQtGui.so.4 11. #10 0xb76e501a in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4 12. #11 0xb76e51da in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4 13. #12 0xb76e7895 in QCoreApplication::exec() () from /usr/lib/libQtCore.so.4 14. #13 0xb6c2c777 in QApplication::exec() () from /usr/lib/libQtGui.so.4 15. #14 0xb80a7960 in kdemain () from /usr/lib/libkdeinit4_kded4.so 16. #15 0x08048722 in _start () Backtrace using Qt-4.5.0-rc1: 1. #0 0xb73e3584 in pthread_mutex_lock () from /lib/libpthread.so.0 2. #1 0xb6067135 in _xcb_lock_io () from /usr/lib/libxcb.so.1 3. #2 0xb607d732 in xcb_xlib_lock () from /usr/lib/libxcb-xlib.so.0 4. #3 0xb670b899 in ?? () from /usr/lib/libX11.so.6 5. #4 0xb66f4afc in XEventsQueued () from /usr/lib/libX11.so.6 6. #5 0xb6a0329d in ?? () from /usr/local/Trolltech/Qt-4.5.0-rc1/lib/libQtGui.so.4 7. #6 0xb61bd5b8 in g_main_context_check () from /usr/lib/libglib-2.0.so.0 8. #7 0xb61bdf4d in ?? () from /usr/lib/libglib-2.0.so.0 9. #8 0xb61be221 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 10. #9 0xb7576628 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () 11. from /usr/local/Trolltech/Qt-4.5.0-rc1/lib/libQtCore.so.4 12. #10 0xb6a030d5 in ?? () from /usr/local/Trolltech/Qt-4.5.0-rc1/lib/libQtGui.so.4 13. #11 0xb75492ca in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () 14. from /usr/local/Trolltech/Qt-4.5.0-rc1/lib/libQtCore.so.4 15. #12 0xb754970a in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () 16. from /usr/local/Trolltech/Qt-4.5.0-rc1/lib/libQtCore.so.4 17. #13 0xb754bb99 in QCoreApplication::exec() () from /usr/local/Trolltech/Qt-4.5.0-rc1/lib/libQtCore.so.4 18. #14 0xb6964127 in QApplication::exec() () from /usr/local/Trolltech/Qt-4.5.0-rc1/lib/libQtGui.so.4 19. #15 0xb7f28960 in kdemain () from /usr/lib/libkdeinit4_kded4.so 20. #16 0x08048722 in _start () strace output: # clock_gettime(CLOCK_MONOTONIC, {3856, 199023312}) = 0 # clock_gettime(CLOCK_MONOTONIC, {3856, 199067607}) = 0 # clock_gettime(CLOCK_MONOTONIC, {3856, 199111636}) = 0 # read(8, 0x8067b84, 4096) = -1 EAGAIN (Resource temporarily unavailable) # poll([{fd=3, events=POLLIN}, {fd=8, events=POLLIN}, {fd=5, events=POLLIN}, {fd=9, events=POLLIN}, {fd=11, events=POLLIN}], 5, 0) = 0 (Timeout) # read(8, 0x8067b84, 4096) = -1 EAGAIN (Resource temporarily unavailable) # clock_gettime(CLOCK_MONOTONIC, {3856, 199310094}) = 0 # clock_gettime(CLOCK_MONOTONIC, {3856, 199354073}) = 0 # clock_gettime(CLOCK_MONOTONIC, {3856, 199398405}) = 0 # read(8, 0x8067b84, 4096) = -1 EAGAIN (Resource temporarily unavailable) # poll([{fd=3, events=POLLIN}, {fd=8, events=POLLIN}, {fd=5, events=POLLIN}, {fd=9, events=POLLIN}, {fd=11, events=POLLIN}], 5, 0) = 0 (Timeout) # read(8, 0x8067b84, 4096) = -1 EAGAIN (Resource temporarily unavailable) # clock_gettime(CLOCK_MONOTONIC, {3856, 199596939}) = 0 # clock_gettime(CLOCK_MONOTONIC, {3856, 199641025}) = 0 # clock_gettime(CLOCK_MONOTONIC, {3856, 199685089}) = 0 # read(8, 0x8067b84, 4096) = -1 EAGAIN (Resource temporar
I am having the same problem on Fedora 11 rawhide using KDE 4.2 (4.2.0-10). When viewing or deleting IMAP messages using kontact/kmail, it almost always freezes for minutes with high hard disk use, and the kontact and the kded process uses 90-100% CPU each. When the kontact process come back to normal, the kded processes still keep using 100% CPU for hours (I think they do not freeze the whole system because I have 4 cores). Backtrace using system Qt 4.5(4.5.0-0.rc1.0): #0 0x002f3416 in __kernel_vsyscall () #1 0x005fc74b in read () from /lib/libpthread.so.0 #2 0x0083efc0 in ?? () from /usr/lib/libxcb.so.1 #3 0x0083f618 in xcb_poll_for_event () from /usr/lib/libxcb.so.1 #4 0x00775009 in ?? () from /usr/lib/libX11.so.6 #5 0x0077530e in ?? () from /usr/lib/libX11.so.6 #6 0x00775c95 in _XEventsQueued () from /usr/lib/libX11.so.6 #7 0x0075e37f in XEventsQueued () from /usr/lib/libX11.so.6 #8 0x02f19265 in ?? () from /usr/lib/libQtGui.so.4 #9 0x00687408 in g_main_context_check () from /lib/libglib-2.0.so.0 #10 0x00687d8d in ?? () from /lib/libglib-2.0.so.0 #11 0x00688061 in g_main_context_iteration () from /lib/libglib-2.0.so.0 #12 0x023f3b5c in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4 #13 0x02f19095 in ?? () from /usr/lib/libQtGui.so.4 #14 0x023c6ba9 in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4 #15 0x023c6ff2 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4 #16 0x023c937f in QCoreApplication::exec() () from /usr/lib/libQtCore.so.4 #17 0x02e795a7 in QApplication::exec() () from /usr/lib/libQtGui.so.4 #18 0x00b584f0 in kdemain () from /usr/lib/libkdeinit4_kded4.so #19 0x08048692 in _start ()
This problem seems to have gone away with recent packages from KDE:KDE4:Factory:Desktop (OpenSUSE) - kdelibs4-4.2.0-100.1.
*** Bug 184576 has been marked as a duplicate of this bug. ***
Any news on this? Thanks
I'm reporting another case of 100% cpu usage of kded4 (on a multi-core system, if that makes any diff). This was seen on kubuntu 9.04. I'll get backtrace when I see it again.
I am having the same problem on Debian testing + kde4 from unstable. kded4 busy loops and eats 100% CPU. poll() is constantly called with zero timeout when there is no data available on all descriptors. --------------------------- strace output: 19:51:12.386911 poll([{fd=3, events=POLLIN}, {fd=8, events=POLLIN}, {fd=5, events=POLLIN}, {fd=9, events=POLLIN}, {fd=11, events=POLLIN}], 5, 0) = 0 (Timeout) 19:51:12.386949 read(8, 0x19fe024, 4096) = -1 EAGAIN (Resource temporarily unavailable) 19:51:12.386972 read(8, 0x19fe024, 4096) = -1 EAGAIN (Resource temporarily unavailable) 19:51:12.386993 poll([{fd=3, events=POLLIN}, {fd=8, events=POLLIN}, {fd=5, events=POLLIN}, {fd=9, events=POLLIN}, {fd=11, events=POLLIN}], 5, 0) = 0 (Timeout) 19:51:12.387018 read(8, 0x19fe024, 4096) = -1 EAGAIN (Resource temporarily unavailable) 19:51:12.387041 read(8, 0x19fe024, 4096) = -1 EAGAIN (Resource temporarily unavailable) .... --------------------------- gdb backtrace: #0 0x00007f6c4576e8f6 in *__GI___poll (fds=0x1a34070, nfds=5, timeout=0) at ../sysdeps/unix/sysv/linux/poll.c:87 #1 0x00007f6c425633af in ?? () from /usr/lib/libglib-2.0.so.0 #2 0x00007f6c425636ac in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 #3 0x00007f6c453db4bf in QEventDispatcherGlib::processEvents () from /usr/lib/libQtCore.so.4 #4 0x00007f6c4338bc7f in ?? () from /usr/lib/libQtGui.so.4 #5 0x00007f6c453b06f2 in QEventLoop::processEvents () from /usr/lib/libQtCore.so.4 #6 0x00007f6c453b0abd in QEventLoop::exec () from /usr/lib/libQtCore.so.4 #7 0x00007f6c453b2d84 in QCoreApplication::exec () from /usr/lib/libQtCore.so.4 #8 0x00007f6c45a07b57 in kdemain () from /usr/lib/libkdeinit4_kded4.so #9 0x00007f6c456c75a6 in __libc_start_main (main=0x4006f0 <_start+240>, argc=1, ubp_av=0x7fff4de2a8c8, init=0x400720 <__libc_csu_init>, fini=<value optimized out>, rtld_fini=<value optimized out>, stack_end=0x7fff4de2a8b8) at libc-start.c:222
Yesterday I updated my gentoo box from qt-4.4.2/kde-4.2.3 to qt-4.5.1/kde-4.2.4. On first login today, kded4 pegged one CPU on 100% while doing (strace): -- 8< -- poll([{fd=3, events=POLLIN}, {fd=8, events=POLLIN}, {fd=5, events=POLLIN}, {fd=9, events=POLLIN}, {fd=11, events=POLLIN}, {fd=15, events=POLLIN}, {fd=16, events=POLLIN}, {fd=12, events=POLLIN}, {fd=19, events=POLLIN}, {fd=20, events=POLLIN}, {fd=17, events=POLLIN}], 11, 0) = 0 (Timeout) ioctl(8, FIONREAD, [0]) = 0 clock_gettime(CLOCK_MONOTONIC, {692108, 960899977}) = 0 clock_gettime(CLOCK_MONOTONIC, {692108, 960915757}) = 0 clock_gettime(CLOCK_MONOTONIC, {692108, 960931349}) = 0 ioctl(8, FIONREAD, [0]) -- 8< -- Killing and restarting kded4 seems to have cooled it down. CPU-usage is minimal, keyboard shortcuts etc seem to work. A gentoo-forum thread [1] indicates that this may be recurring on reboot, but I haven't done this yet. [1] http://forums.gentoo.org/viewtopic-t-736439-start-50.html?sid=ddf71c34a6bcb0fe85d746434db550e4
I had the same problem, and I finally tracked it down to a problem with how glib was compiled. If I compiled it with an optimization level higher than -O2 this happens. Changing the compile optimization down to -O2 instead of -O3 for glib fixed it. Hopefully this will help some of you too.
*** Bug 193408 has been marked as a duplicate of this bug. ***
This propably the same problem as bug# 206317 /Carsten - Denmark
Confirmed on KDE 4.3.2 (Debian amd64), Qt 4.6.0 beta (Debian version 4.6.0~beta1-1) on a Thinkpad laptop with Intel Core 2 Duo. ~$ strace -t -p 5172: 13:14:43 read(8, 0x6a1db4, 4096) = -1 EAGAIN (Resource temporarily unavailable) 13:14:43 read(8, 0x6a1db4, 4096) = -1 EAGAIN (Resource temporarily unavailable) 13:14:43 poll([{fd=3, events=POLLIN}, {fd=8, events=POLLIN}, {fd=5, events=POLLIN}, {fd=9, events=POLLIN}, {fd=11, events=POLLIN}, {fd=12, events=POLLIN}], 6, 0) = 0 (Timeout) 13:14:43 read(8, 0x6a1db4, 4096) = -1 EAGAIN (Resource temporarily unavailable) 13:14:43 read(8, 0x6a1db4, 4096) = -1 EAGAIN (Resource temporarily unavailable) 13:14:43 poll([{fd=3, events=POLLIN}, {fd=8, events=POLLIN}, {fd=5, events=POLLIN}, {fd=9, events=POLLIN}, {fd=11, events=POLLIN}, {fd=12, events=POLLIN}], 6, 0) = 0 (Timeout) 13:14:43 read(8, 0x6a1db4, 4096) = -1 EAGAIN (Resource temporarily unavailable) 13:14:43 read(8, 0x6a1db4, 4096) = -1 EAGAIN (Resource temporarily unavailable) 13:14:43 poll([{fd=3, events=POLLIN}, {fd=8, events=POLLIN}, {fd=5, events=POLLIN}, {fd=9, events=POLLIN}, {fd=11, events=POLLIN}, {fd=12, events=POLLIN}], 6, 0) = 0 (Timeout) ...repeats endlessly ~$ ltrace -TSp 5172 SYS_read(8, "\001 \006f\001", 4096) = -11 <0.000014> SYS_read(8, "\001 \006f\001", 4096) = -11 <0.000014> SYS_poll(0x00b80200, 6, 0) = 0 <0.000015> SYS_read(8, "\001 \006f\001", 4096) = -11 <0.000014> SYS_read(8, "\001 \006f\001", 4096) = -11 <0.000014> SYS_poll(0x00b80200, 6, 0) = 0 <0.000016> SYS_read(8, "\001 \006f\001", 4096) = -11 <0.000014> SYS_read(8, "\001 \006f\001", 4096) = -11 <0.000014> SYS_poll(0x00b80200, 6, 0) = 0 <0.000016> SYS_read(8, "\001 \006f\001", 4096) = -11 <0.000014> SYS_read(8, "\001 \006f\001", 4096) = -11 <0.000014> SYS_poll(0x00b80200, 6, 0) = 0 <0.000016> SYS_read(8, "\001 \006f\001", 4096) = -11 <0.000014> SYS_read(8, "\001 \006f\001", 4096) = -11 <0.000014>
*** This bug has been confirmed by popular vote. ***
Created attachment 37735 [details] gdb full stack trace
Created attachment 37736 [details] oprofile report OProfile report generated with: ~# opcontrol --separate=lib,thread --no-vmlinux --start ... wait a minute or so) ~# opreport tgid:5172 -l -g
If possible you might try recompiling glib with a lower optimization level. I recompiled my glib with -O2 instead of -O3, and it solved the problem. Looking at your backtrace it seems to be happening the same place mine was.
(In reply to comment #19) > If possible you might try recompiling glib with a lower optimization level. I > recompiled my glib with -O2 instead of -O3, and it solved the problem. AFAICS Debian already compiles glib with -O2.
SVN commit 1075552 by dfaure: Fix 100% CPU usage due to a startTimer(0) that was never stopped; this could happen if the timer was started twice, so m_timerId was overwritten, and the first timer ID never recognized. It's much much simpler to use deleteLater: no risk of forgetting the deletion and no risk of timers running forever. It means using QWeakPointer to notice when it got deleted, though. CCMAIL: kretz@kde.org I'm not sure which of the "kded uses 100% cpu" bugs this really fixes; maybe all, or maybe just the one that talks about phonon specifically... Fixed for: 4.4 BUG: 202744 CCBUG: 178228 CCBUG: 184576 CCBUG: 217364 CCBUG: 220047 M +16 -34 hardwaredatabase.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1075552
*** Bug 268907 has been marked as a duplicate of this bug. ***
(In reply to comment #21) > I'm not sure which of the "kded uses 100% cpu" bugs this really fixes; maybe > all, no, please see bug #268907
I found out why this happens on my machine. First of all, I don't have network manager plasma applet or any gui network configuation tool available on my distribution. I connect to the internet using rp-pppoe package which dials my pppoe connection at boot. How I reproduce this bug: Sometimes I disconnect many times a day and when I get reconnected, kded4 starts using 95 to 98% CPU. Sometimes even more than one kded4 process spawns for some reason. kde 4.6.1 on archlinux. qt 4.7.2 ntrack 013 kernel 2.6.38.2 I'm new to KDE as I have been experimenting with multiple DEs this month so if I can get more related information, please let me know.
Created attachment 58821 [details] back trace under KDE 4.6.2 This backtrace was made under KDE 4.6.2 with "thread apply all bt full"
Under KDE 4.6.2 it seems that this issue happens when an external VGA monitor is pugged on/off and xrandr is used to change the virtual screen size.
Disconnecting a VPN connection (PPTP) causes 100% cpu load of kded4, too. I'll provide a stacktrace, asap.
I can reproduce the same phenomenon (kded4 goes wild, has to be killed) in this way: * KDE Networkmanager Applet connected to any WLAN, connect to any VPN-Network (vpnc) do either 1 disconnect or reconnect the wlan connection when vpn is running or 2 disconnect the vpn connection Kded4 goes immediately to 100%, the vpn-connection continues to show "connected"
This issue happens to me sometimes when I logout and login.
maybe this bug is deplicate for https://bugs.kde.org/show_bug.cgi?id=268038 ?
(In reply to comment #30) > maybe this bug is deplicate for https://bugs.kde.org/show_bug.cgi?id=268038 ? NO, I run Gentoo and haven't any ntrack related files here
I wrote comment 28. I am running Kubuntu 11.4. ntrack is installed on my system, but there is no thread named ntrack. Can I force the system to not use ntrack and test if the bug is related?
The ntrack issue will trigger the behavior in this bug. I can confirm this on ArchLinux with ntrack 013. But there are other issues too that seem to trigger this bug as well.
I experienced an 100% kde4d process after I suspend my docked ThinkPad (internal display off, external DVI display on), undocked it, plugged in an external VGA monitor and resume the ThinkPad to use a dual-head configuration.
(In reply to comment #34) > I experienced an 100% kde4d process after I suspend my docked ThinkPad > (internal display off, external DVI display on), undocked it, plugged in an > external VGA monitor and resume the ThinkPad to use a dual-head configuration. And I'm wondering whether it might be related to missing devices - a LINUX kernel related issue was discussed here : https://bugzilla.kernel.org/show_bug.cgi?id=15100#add_comment
Similar to bug 206317 I am closing this bug, because it has been split for each kded4 module that causes 100% CPU or hangs on exit. - Network Status module: should work with Ntrack 013, see bug 268038 - Solid QFileSystemWatcher: see bug 257493, bug 269648, bug 265400 comment #24 The Solid bug should be fixed in KDE 4.7.0. Please add comments to those bugs. If you get a hanging kded4 (both with 100% CPU or idling) that are unrelated to the modules mentioned above, please report a new bug or add a comment here. For more information about kded4, see http://kdepepo.wordpress.com/2011/05/11/troubleshooting-kded4-bugs/ Additional note: Similar issues with "knotify4" are likely Phonon related. If knotify4 is among the processes that hangs, please first try updating Phonon and switching Phonon backend to latest phonon-gstreamer or phonon-vlc. The phonon-xine backend is no longer maintained.