Bug 257493 - KDE 4.5.77: kded 100% CPU apparently in Solid module
Summary: KDE 4.5.77: kded 100% CPU apparently in Solid module
Alias: None
Product: solid
Classification: Unclassified
Component: libsolid-fstab (show other bugs)
Version: unspecified
Platform: Mandriva RPMs Linux
: NOR normal with 50 votes (vote)
Target Milestone: ---
Assignee: Mario Bensi
: 259388 263508 (view as bug list)
Depends on:
Reported: 2010-11-21 10:21 UTC by Andrey Borzenkov
Modified: 2013-07-28 21:29 UTC (History)
9 users (show)

See Also:
Latest Commit:
Version Fixed In:


Note You need to log in before you can comment on or make changes to this bug.
Description Andrey Borzenkov 2010-11-21 10:21:58 UTC
Version:           unspecified (using Devel) 
OS:                Linux

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

(gdb) bt
#0  0x00007f5c335b323c in pthread_cond_wait@@GLIBC_2.3.2 ()
   from /lib64/libpthread.so.0
#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>)
    at io/qfilesystemwatcher.cpp:440
#5  0x00007f5c338f3f99 in QFileSystemWatcher::~QFileSystemWatcher (
    this=0x251b310, __in_chrg=<value optimized out>)
    at io/qfilesystemwatcher.cpp:456
#6  0x00007f5c339321d4 in QObjectPrivate::deleteChildren (this=0x2598fb0)
    at kernel/qobject.cpp:1949
#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>)
    at /usr/src/debug/kdelibs-4.5.77svn1198704/solid/solid/backends/fstab/fstabwatcher.cpp:51
#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 ()
    at kernel/qapplication_x11.cpp:773
#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)
    at GetSOwner.c:41
#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)
    at kernel/qcoreapplication.cpp:732
#19 0x00007f5c32ad56ab in sendEvent (this=0x7fff57879c00,
    __in_chrg=<value optimized out>)
    at ../../src/corelib/kernel/qcoreapplication.h:215
#20 QApplication::~QApplication (this=0x7fff57879c00,
    __in_chrg=<value optimized out>) at kernel/qapplication.cpp:1079
#21 0x00007f5c2070232e in kdemain (argc=1, argv=0x233f260)
    at /usr/src/debug/kdelibs-4.5.77svn1198704/kded/kded.cpp:897
#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,
    startup_id_str=0x40b4c1 "0")
    at /usr/src/debug/kdelibs-4.5.77svn1198704/kinit/kinit.cpp:730
#23 0x0000000000409067 in main (argc=4, argv=0x7fff5787a498,
    at /usr/src/debug/kdelibs-4.5.77svn1198704/kinit/kinit.cpp:1844
(gdb) q
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

Reproducible: Sometimes

Steps to Reproduce:
Comment 1 Kevin Ottens 2010-11-24 18:37:30 UTC
Seem related to the fstab backend. Sounds like something difficult to reproduce though. Reassigning on the right component.
Comment 2 Lamarque V. Souza 2011-02-04 15:52:16 UTC
*** Bug 263508 has been marked as a duplicate of this bug. ***
Comment 3 Lamarque V. Souza 2011-02-04 16:08:19 UTC
*** Bug 259388 has been marked as a duplicate of this bug. ***
Comment 4 Bradey Honsinger 2011-04-14 19:22:55 UTC
*** This bug has been confirmed by popular vote. ***
Comment 5 Niko Sams 2011-05-14 11:58:43 UTC
Same issue here with KDE 4.6.2 on Gentoo.
Exactly the same backtrace for 4 running kded4 processes as Andrey posted.
Comment 6 George Kiagiadakis 2011-05-15 20:03:27 UTC
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.
Comment 7 Mario Bensi 2011-05-16 17:38:01 UTC
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

Comment 8 Alan Ezust 2011-06-19 19:17:47 UTC
I am getting this now too, after a recent upgrade in debian testing.
Googling around, I found another issue that seems related.

Comment 9 Lisandro Damián Nicanor Pérez Meyer 2011-07-15 13:23:19 UTC
In [0] it has been suggested that this bug is the same as [1] and can be worked around by:

You can use ~/.kde/shutdown/kded4.sh script with this command:
killall -9 kded4

[0] <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=621358#34>
[1] <https://bugs.kde.org/show_bug.cgi?id=265400>
Comment 10 Stefan Majewsky 2011-07-15 13:53:38 UTC
(In reply to comment #9)
> In [0] it has been suggested that this bug is the same as [1]

This bug is unrelated to logout, it appears during the session.
Comment 11 Alex Fiestas 2013-03-14 02:08:17 UTC
This should be fixed now, both ntrack and fstab issue.

Can anyone reproduce this?
Comment 12 Alex Fiestas 2013-07-28 21:29:11 UTC
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 !