Bug 259388 - kded4 has ~100% CPU load
Summary: kded4 has ~100% CPU load
Status: RESOLVED DUPLICATE of bug 257493
Alias: None
Product: kdelibs
Classification: Frameworks and Libraries
Component: kded (show other bugs)
Version: unspecified
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: David Faure
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-12-10 00:20 UTC by Stefan Majewsky
Modified: 2011-02-04 16:08 UTC (History)
6 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Stefan Majewsky 2010-12-10 00:20:15 UTC
Version:           unspecified (using KDE 4.5.85) 
OS:                Linux

Since the update to 4.6 Beta 2, kded4 uses all available CPU time on my dual-core, thereby massively slowing the desktop and applications even after renicing the kded4 processes in question to very low priority. This behavior did not occur in 4.6 Beta 1.

Is there any way I can supply you with more information about this problem?

Reproducible: Always

Steps to Reproduce:
1. Start Plasma desktop session.
2. (e.g.) Start Konqueror, enter a URL.

Actual Results:  
See it hang for 10 seconds before starting to load the webpage.

Expected Results:  
Have it load the webpage (or whatever) immediately.
Comment 1 Christoph Feck 2010-12-10 00:49:51 UTC
You could remove a one of the .desktop files in KDEDIR/share/kde4/services/kded/ and restart kded4. If you found the offending module, report a new bug, or add a comment here.
Comment 2 Stefan Majewsky 2010-12-10 12:02:17 UTC
Is it possible to restart kded4 cleanly while running a KDE workspace (i.e. a startkde session)? I tried to do some diagnostics in a TWM session in which I started kded4 via `kcmshell4 kcmkded` (previous attempts to start `kded4` resulted in very weird 
behaviors, like kded not replying to DBus introspection calls).

I had disabled all modules in the KCM so `qdbus org.kde.kded /kded loadedModules` returned an empty list when kded4 was launched from TWM. Then I loaded the modules one after the other with `qdbus org.kde.kded /kded loadModule`. All modules loaded successfully, but even when all modules where loaded, kded's CPU usage was below 1% (the precision of `top`).

Even more interestingly, though, is that the high CPU load problem has suddenly disappeared in my KDE sessions as well. My conclusion is that, if the incident was not isolated, it must have something to do with the modules that are only loaded on demand, and the issue appears only if these modules are really used. For your information, the following modules are *not* loaded ATM:

desktopnotifier kephal kpasswdserver kssld ksvnd networkwatcher proxyscout soliduiserver

For most of these modules, I do not even know which applications use them (e.g. I expect "kephal" to be used by `kcmshell4 display` and Plasma, but it won't load).
Comment 3 Stefan Majewsky 2010-12-13 21:40:30 UTC
Still interesting. There's again one kded process at 50% (i.e. one core) CPU load. Only one, not two this time. Will investigate this later.
Comment 4 Stefan Majewsky 2010-12-13 23:50:27 UTC
More results: I have shutdown all kdelibs-powered GUI apps (from Amarok to Plasma to KMix) except for a Konsole, where I unloaded kded modules (via DBus) until the list of loaded modules (as reported via DBus) was empty. The CPU load stayed at the same 50% (i.e. one full core). Nothing useful up to now, except for the information that no module seems to be responsible for the load (considering esp. that all "unloadModule" DBus calls returned "true" immediately).

I could get a reproducible backtrace by attaching a GDB to the running kded (reproducible as in: I get the same if I continue the process, see its load go up to the usual 50% again, interrupt and backtrace it again). Looks like a deadlock to me.

#0  0xffffe424 in __kernel_vsyscall ()
#1  0xb6ce6125 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
#2  0xb6d5daa0 in wait (this=0x8154f18, mutex=0x8154f00, time=4294967295)
    at thread/qwaitcondition_unix.cpp:88
#3  QWaitCondition::wait (this=0x8154f18, mutex=0x8154f00, time=4294967295)
    at thread/qwaitcondition_unix.cpp:160
#4  0xb6d5cac5 in QThread::wait (this=0x818ea90, time=4294967295)
    at thread/qthread_unix.cpp:683
#5  0xb6e2dfa5 in QFileSystemWatcher::~QFileSystemWatcher (this=0x80945d8,
    __in_chrg=<value optimized out>) at io/qfilesystemwatcher.cpp:440
#6  0xb6e2e072 in QFileSystemWatcher::~QFileSystemWatcher (this=0x80945d8,
    __in_chrg=<value optimized out>) at io/qfilesystemwatcher.cpp:456
#7  0xb6e702c4 in QObjectPrivate::deleteChildren (this=0x8156028)
    at kernel/qobject.cpp:1949
#8  0xb6e7517c in QObject::~QObject (this=0x822ba08,
    __in_chrg=<value optimized out>) at kernel/qobject.cpp:945
#9  0xb52c22eb in Solid::Backends::Fstab::FstabWatcher::~FstabWatcher (this=
    0x822ba08, __in_chrg=<value optimized out>)
    at /usr/src/debug/kdelibs-4.5.85/solid/solid/backends/fstab/fstabwatcher.cpp:48
#10 0xb52c2322 in Solid::Backends::Fstab::FstabWatcher::~FstabWatcher (this=
    0x822ba08, __in_chrg=<value optimized out>)
    at /usr/src/debug/kdelibs-4.5.85/solid/solid/backends/fstab/fstabwatcher.cpp:51
#11 0xb52c2182 in destroy ()
    at /usr/src/debug/kdelibs-4.5.85/solid/solid/backends/fstab/fstabwatcher.cpp:30
#12 0xb524eb89 in Solid::CleanUpGlobalStatic::~CleanUpGlobalStatic (this=
    0xb52f75cc, __in_chrg=<value optimized out>)
    at /usr/src/debug/kdelibs-4.5.85/solid/solid/soliddefs_p.h:67
#13 0xb5fec7cf in __run_exit_handlers () from /lib/libc.so.6
#14 0xb5fec82d in exit () from /lib/libc.so.6
#15 0xb63d16e8 in qt_xio_errhandler () at kernel/qapplication_x11.cpp:773
#16 0xb7292504 in _XIOError () from /usr/lib/libX11.so.6
#17 0xb72992b8 in ?? () from /usr/lib/libX11.so.6
#18 0xb7299a5d in _XReply () from /usr/lib/libX11.so.6
#19 0xb7276c39 in XGetSelectionOwner () from /usr/lib/libX11.so.6
#20 0xb63eaa95 in QClipboard::event (this=0x80b2338, e=0xfffffe00)
    at kernel/qclipboard_x11.cpp:926
#21 0xb6358414 in QApplicationPrivate::notify_helper (this=0x80b2348, receiver=
    0x80b2338, e=0xbffef7c8) at kernel/qapplication.cpp:4445
#22 0xb6361137 in QApplication::notify (this=0xbffef890, receiver=0x80b2338, e=
    0xbffef7c8) at kernel/qapplication.cpp:3845
#23 0xb6e5c5be in QCoreApplication::notifyInternal (this=0xbffef890, receiver=
    0x80b2338, event=0xbffef7c8) at kernel/qcoreapplication.cpp:732
#24 0xb636022d in sendEvent (this=0xbffef890, __in_chrg=<value optimized out>)
    at ../../src/corelib/kernel/qcoreapplication.h:215
#25 QApplication::~QApplication (this=0xbffef890, __in_chrg=<value optimized out>)
    at kernel/qapplication.cpp:1079
#26 0xb74907c8 in KApplication::~KApplication (this=0xbffef890,
    __in_chrg=<value optimized out>)
    at /usr/src/debug/kdelibs-4.5.85/kdeui/kernel/kapplication.cpp:892
#27 0xb7490838 in KUniqueApplication::~KUniqueApplication (this=0xbffef890,
    __in_chrg=<value optimized out>)
    at /usr/src/debug/kdelibs-4.5.85/kdeui/kernel/kuniqueapplication.cpp:343
#28 0xb54b93b2 in kdemain () from /usr/lib/libkdeinit4_kded4.so
#29 0x0804e521 in _start ()
Comment 5 bill p. (aka google01103) 2011-01-06 14:44:46 UTC
have this problem when restarting kde with alt+ctrl+bksp in  4.5.95 (4.6 RC2) under 64bit openSuse
Comment 6 Michael Meier 2011-01-13 23:57:09 UTC
Same problem here with KDE4 4.5.95.
Comment 7 Friedrich W. H. Kossebau 2011-01-17 15:11:08 UTC
I see the same with 4.5.5 (Kubunutu) and remember to have seen it with versions before. Might only have happened after wake-up from suspend, but not sure.
Comment 8 Lamarque V. Souza 2011-02-04 16:08:19 UTC

*** This bug has been marked as a duplicate of bug 257493 ***