Bug 178228

Summary: kded4 makes high CPU load and hangs ths system on STOP signal
Product: kdelibs Reporter: squan
Component: kdedAssignee: David Faure <faure>
Status: RESOLVED NOT A BUG    
Severity: crash CC: abram, alessandro.ufms, alexander.fieroch, amg1127, andresbajotierra, carstenobel, cfeck, chaz, costexx, cunha17, cwehrmann, doochik, faure, finex, fire, franke.daniel, ht990332, joedmorris, konstantin.stepanyuk, l.appelhans, mailjohnmorris, marcus, stephan.diestelhorst, toralf.foerster, wrana
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: Compiled Sources   
OS: Linux   
Latest Commit: Version Fixed In:
Attachments: gdb full stack trace
oprofile report
back trace under KDE 4.6.2

Description squan 2008-12-19 22:23:58 UTC
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
Comment 1 FiNeX 2008-12-20 23:48:14 UTC
@Lukas: is this fault of kget?
Comment 2 David Faure 2008-12-22 12:27:21 UTC
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.
Comment 3 squan 2008-12-26 13:35:19 UTC
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 ()
	
Comment 4 Chris Hills 2009-02-11 12:11:26 UTC
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
Comment 5 Cristiano da Cunha Duarte 2009-02-17 15:54:48 UTC
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 ()
Comment 6 Chris Hills 2009-02-19 13:36:04 UTC
This problem seems to have gone away with recent packages from KDE:KDE4:Factory:Desktop (OpenSUSE) - kdelibs4-4.2.0-100.1.
Comment 7 David Faure 2009-02-19 14:05:32 UTC
*** Bug 184576 has been marked as a duplicate of this bug. ***
Comment 8 Dario Andres 2009-04-17 16:46:32 UTC
Any news on this? Thanks
Comment 9 Abram Catalano 2009-05-05 18:29:36 UTC
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.
Comment 10 Konstantin Stepanyuk 2009-05-14 17:56:15 UTC
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
Comment 11 Daniel Franke 2009-06-07 12:01:41 UTC
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
Comment 12 John Morris 2009-08-10 07:15:12 UTC
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.
Comment 13 David Faure 2009-10-02 18:31:42 UTC
*** Bug 193408 has been marked as a duplicate of this bug. ***
Comment 14 Carsten Obel Mortensen 2009-10-03 23:17:46 UTC
This propably the same problem as bug# 206317

/Carsten - Denmark
Comment 15 Marcus Better 2009-10-22 13:17:25 UTC
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>
Comment 16 Marcus Better 2009-10-22 13:24:42 UTC
*** This bug has been confirmed by popular vote. ***
Comment 17 Marcus Better 2009-10-22 13:25:49 UTC
Created attachment 37735 [details]
gdb full stack trace
Comment 18 Marcus Better 2009-10-22 13:54:05 UTC
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
Comment 19 John Morris 2009-10-22 18:25:44 UTC
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.
Comment 20 Marcus Better 2009-10-22 18:32:29 UTC
(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.
Comment 21 David Faure 2010-01-16 12:07:20 UTC
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
Comment 22 Lamarque V. Souza 2011-03-19 21:20:26 UTC
*** Bug 268907 has been marked as a duplicate of this bug. ***
Comment 23 Toralf Förster 2011-03-19 23:05:07 UTC
(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
Comment 24 Hussam Al-Tayeb 2011-03-30 17:36:09 UTC
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.
Comment 25 Toralf Förster 2011-04-12 13:04:45 UTC
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"
Comment 26 Toralf Förster 2011-04-28 11:43:14 UTC
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.
Comment 27 Bernhard Jungk 2011-05-02 17:05:18 UTC
Disconnecting a VPN connection (PPTP) causes 100% cpu load of kded4, too. I'll provide a stacktrace, asap.
Comment 28 Daniel Wrana 2011-05-05 07:55:05 UTC
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"
Comment 29 Alessandro Nakamuta 2011-05-08 20:07:16 UTC
This issue happens to me sometimes when I logout and login.
Comment 30 Alexey Androsov 2011-05-18 05:22:21 UTC
maybe this bug is deplicate for https://bugs.kde.org/show_bug.cgi?id=268038 ?
Comment 31 Toralf Förster 2011-05-18 10:05:01 UTC
(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
Comment 32 Daniel Wrana 2011-05-18 14:46:06 UTC
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?
Comment 33 Hussam Al-Tayeb 2011-05-18 16:13:37 UTC
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.
Comment 34 Toralf Förster 2011-05-25 09:45:50 UTC
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.
Comment 35 Toralf Förster 2011-06-01 09:45:45 UTC
(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
Comment 36 Christoph Feck 2011-07-28 16:30:19 UTC
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.