Version: unspecified (using Devel)
KDE 4.5.77 (r1198704), Qt 4.7.1 in Mandriva.
Since update to 4.5.77 kded several times started to consume 100% CPU. Killing it allowed it to restart and return to normal.
Last time I tried strace and gdb; here is output. 5055 is the PID that was shown with 100% CPU in top.
pts/0}% strace -p 5055
Process 5055 attached - interrupt to quit
futex(0x257c66c, FUTEX_WAIT_PRIVATE, 1, NULL^C <unfinished ...>
Process 5055 detached
#0 0x00007f5c335b323c in pthread_cond_wait@@GLIBC_2.3.2 ()
#1 0x00007f5c33836e2b in wait (this=<value optimized out>, mutex=0x25991a0,
time=18446744073709551615) at thread/qwaitcondition_unix.cpp:88
#2 QWaitCondition::wait (this=<value optimized out>, mutex=0x25991a0,
time=18446744073709551615) at thread/qwaitcondition_unix.cpp:160
#3 0x00007f5c33835ee0 in QThread::wait (this=<value optimized out>,
time=18446744073709551615) at thread/qthread_unix.cpp:683
#4 0x00007f5c338f3ec0 in QFileSystemWatcher::~QFileSystemWatcher (
this=<value optimized out>, __in_chrg=<value optimized out>)
#5 0x00007f5c338f3f99 in QFileSystemWatcher::~QFileSystemWatcher (
this=0x251b310, __in_chrg=<value optimized out>)
#6 0x00007f5c339321d4 in QObjectPrivate::deleteChildren (this=0x2598fb0)
#7 0x00007f5c33936d12 in QObject::~QObject (this=0x259b4a0,
__in_chrg=<value optimized out>) at kernel/qobject.cpp:945
#8 0x00007f5c2a4d8249 in Solid::Backends::Fstab::FstabWatcher::~FstabWatcher (
this=0x259b4a0, __in_chrg=<value optimized out>)
#9 0x00007f5c322d1fa1 in __run_exit_handlers () from /lib64/libc.so.6
#10 0x00007f5c322d1ff5 in exit () from /lib64/libc.so.6
#11 0x00007f5c32b38948 in qt_xio_errhandler ()
#12 0x00007f5c3417313e in _XIOError (dpy=0x2372410) at XlibInt.c:1602
#13 0x00007f5c34170f67 in _XReply (dpy=0x2372410, rep=0x7fff57879300, extra=0,
discard=1) at xcb_io.c:632
#14 0x00007f5c34155743 in XGetSelectionOwner (dpy=0x2372410, selection=356)
#15 0x00007f5c32b506d7 in QClipboard::event (this=0x236a9c0,
e=<value optimized out>) at kernel/qclipboard_x11.cpp:926
#16 0x00007f5c32acc3b4 in QApplicationPrivate::notify_helper (this=0x236aa10,
receiver=0x236a9c0, e=0x7fff57879b10) at kernel/qapplication.cpp:4445
#17 0x00007f5c32ad0eca in QApplication::notify (this=<value optimized out>,
receiver=0x236a9c0, e=0x7fff57879b10) at kernel/qapplication.cpp:4324
#18 0x00007f5c3391f74c in QCoreApplication::notifyInternal (
---Type <return> to continue, or q <return> to quit---
this=0x7fff57879c00, receiver=0x236a9c0, event=0x7fff57879b10)
#19 0x00007f5c32ad56ab in sendEvent (this=0x7fff57879c00,
__in_chrg=<value optimized out>)
#20 QApplication::~QApplication (this=0x7fff57879c00,
__in_chrg=<value optimized out>) at kernel/qapplication.cpp:1079
#21 0x00007f5c2070232e in kdemain (argc=1, argv=0x233f260)
#22 0x0000000000407a1a in launch (argc=<value optimized out>,
_name=0x40b75a "kded4", args=<value optimized out>, cwd=0x0, envc=0,
envs=<value optimized out>, reset_env=false, tty=0x0, avoid_loops=false,
#23 0x0000000000409067 in main (argc=4, argv=0x7fff5787a498,
A debugging session is active.
Inferior 1 [process 5055] will be detached.
Quit anyway? (y or n) y
Detaching from program: /usr/bin/kdeinit4, process 5055
Steps to Reproduce:
Seem related to the fstab backend. Sounds like something difficult to reproduce though. Reassigning on the right component.
*** Bug 263508 has been marked as a duplicate of this bug. ***
*** Bug 259388 has been marked as a duplicate of this bug. ***
*** This bug has been confirmed by popular vote. ***
Same issue here with KDE 4.6.2 on Gentoo.
Exactly the same backtrace for 4 running kded4 processes as Andrey posted.
Unfortunately this is a very common bug. It seems that kded never exits properly, it always hits the qt_xio_errhandler().
See also http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=621358
The problem is that qt_xio_errhandler() kills the QCoreApplication event delivering mechanism, however QFileSystemWatcher requires it in order to destruct itself. It needs to send an event to its polling thread to instruct it to quit, however that event cannot be delivered inside the polling thread because the event delivering mechanism is dead and it stucks in the event loop calling poll(), which returns immediately (because there *are* pending events) and thus keeps the cpu busy entering and exiting the poll() system call... Unfortunately, there seems to be no way to handle this once qt_xio_errhandler() has run.
This is really a Qt bug imho, but the Qt docs mention it:
"Note: To avoid deadlocks on shutdown, all instances of QFileSystemWatcher need to be destroyed before QCoreApplication."
...so it seems that one should not be using a QFileSystemWatcher this way.
I removed the deletion of QFileSystemWatcher from KDE 4.6.2
I don't know how QFileSystemWatcher could be destroy by fstab solid backend.
If you want check the change, i give you the urls of this change :
Actually i can't reproduce this bug on master and on my pc with 4.6.2 and 4.6.3, if you have a way to reproduce this, I will able to fix this
I am getting this now too, after a recent upgrade in debian testing.
Googling around, I found another issue that seems related.
In  it has been suggested that this bug is the same as  and can be worked around by:
You can use ~/.kde/shutdown/kded4.sh script with this command:
killall -9 kded4
(In reply to comment #9)
> In  it has been suggested that this bug is the same as 
This bug is unrelated to logout, it appears during the session.
This should be fixed now, both ntrack and fstab issue.
Can anyone reproduce this?
Closing the thread for lack of activity.
Please, please! if you are still able to reproduce this with KDE 4.10 or 4.11 feel free to reopen the bug!
Thanks for reporting !