Bug 497314 - After upgrade to kde-4.2.2 the kded4 started to hog the CPU
After upgrade to kde-4.2.2 the kded4 started to hog the CPU
Product: Fedora
Classification: Fedora
Component: kdelibs (Show other bugs)
All Linux
low Severity high
: ---
: ---
Assigned To: Ngo Than
Fedora Extras Quality Assurance
: 497765 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2009-04-23 07:08 EDT by Jaroslav Franek
Modified: 2009-05-30 22:30 EDT (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-05-30 22:30:59 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
stacktrace gathered with gdb> thread apply all bt (3.61 KB, text/plain)
2009-04-28 08:13 EDT, Oliver Henshaw
no flags Details
result of ltrace -TSp (647 bytes, text/plain)
2009-04-28 08:19 EDT, Oliver Henshaw
no flags Details
sysprof profile gathered with the gnome-git version of sysprof (34.54 KB, application/x-gzip)
2009-04-28 08:22 EDT, Oliver Henshaw
no flags Details

External Trackers
Tracker ID Priority Status Summary Last Updated
KDE Software Compilation 178228 None None None Never

  None (edit)
Description Jaroslav Franek 2009-04-23 07:08:53 EDT
Description of problem:
kded4 hogging the CPU since the upgrade to 4.2.2

top - 12:56:32 up 33 min, 10 users,  load average: 1.14, 1.08, 0.97
Tasks: 171 total,   2 running, 169 sleeping,   0 stopped,   0 zombie
Cpu(s): 33.8%us, 18.6%sy,  0.0%ni, 45.4%id,  1.8%wa,  0.0%hi,  0.3%si,  0.0%st
Mem:   2058888k total,  1324172k used,   734716k free,    28072k buffers
Swap:  4095992k total,        0k used,  4095992k free,   628204k cached

 3353 franekj   20   0  631m  24m  17m R 99.4  1.2  30:49.38 kded4
 2938 root      20   0  247m  40m 8580 S  3.0  2.0   1:00.98 X
 3452 franekj   20   0  373m  26m  15m S  1.7  1.3   0:01.19 konsole
 3706 franekj   20   0  283m  12m 7832 S  1.7  0.6   0:25.51 gkrellm
 2260 dbus      20   0 34552 1912  904 S  0.3  0.1   0:02.74 dbus-daemon
 3709 franekj   20   0  497m  42m  17m S  0.3  2.1   0:01.76 guidance-power-
 3712 franekj   20   0  551m  34m  17m S  0.3  1.7   0:01.47 pidgin
 3864 franekj   20   0  723m 135m  26m S  0.3  6.7   0:43.41 firefox
 6157 franekj   20   0 14880 1200  872 R  0.3  0.1   0:01.22 top

Version-Release number of selected component (if applicable):

How reproducible:
Upgraded to kde-4.2.2 through yum update, restarted the system

Steps to Reproduce:
Actual results:
 3353 franekj   20   0  631m  24m  17m R 99.4  1.2  30:49.38 kded4

$ ps -eLf | grep kded4
franekj   3353     1  3353 97    3 12:24 ?        00:38:52 kded4
franekj   3353     1  3822  0    3 12:25 ?        00:00:00 kded4
franekj   3353     1  4520  0    3 12:31 ?        00:00:00 kded4

kded4 running on a single CPU core (or jumping between the two cores) since the upgrade for an hour now. Causing a lot of heat in the laptop. Apparently one thread is executing some very long (infinite?) loop.

Expected results:
kded4 does not waste CPU cycles.

Additional info:
Noticed on both my systems: x86_64 and i386.
Comment 1 Jaroslav Franek 2009-04-23 08:24:54 EDT
$ gdb --pid=3353

(gdb) info threads
  3 Thread 0x7fb0443a8950 (LWP 3822)  0x0000003b732dc886 in __poll (fds=0x7fb03c0021c0, nfds=2, timeout=-1)
    at ../sysdeps/unix/sysv/linux/poll.c:87
  2 Thread 0x7fb0483a9950 (LWP 4520)  0x0000003b732deaa2 in select () from /lib64/libc.so.6
* 1 Thread 0x7fb05c289810 (LWP 3353)  0xffffffffff60013b in ?? ()
Current language:  auto; currently c
(gdb) bt
#0  0xffffffffff60013b in ?? ()
#1  0x00007fff67ac39a0 in ?? ()
#2  0x00007fff67bff6fc in vgetns () at arch/x86/vdso/vclock_gettime.c:39
#3  do_monotonic (ts=0x7fff67ac39f0) at arch/x86/vdso/vclock_gettime.c:78
Backtrace stopped: frame did not save the PC
(gdb) cont
Program received signal SIGINT, Interrupt.
0xffffffffff60013b in ?? ()
(gdb) bt
#0  0xffffffffff60013b in ?? ()
#1  0x00007fff67ac39a0 in ?? ()
#2  0x00007fff67bff6fc in vgetns () at arch/x86/vdso/vclock_gettime.c:39
#3  do_monotonic (ts=0x7fff67ac39f0) at arch/x86/vdso/vclock_gettime.c:78
Backtrace stopped: frame did not save the PC
Comment 2 Kevin Kofler 2009-04-23 12:55:35 EDT
I've seen that on my laptop (F10 x86_64) yesterday (yes, I was still running 4.2.1 before). My "solution": killall kded4 and reboot again. That "fixed" it for me.

My main desktop got hit by it now (I hadn't restarted it after yesterday's update), I just shot down kded4 with killall here too and restarted it, seems to have "fixed" it.

I have no idea what kded4 is doing eating CPU power like mad.
Comment 3 Kevin Kofler 2009-04-23 13:00:18 EDT
(PS: My main desktop is F9 i386.)
Comment 4 Jaroslav Reznik 2009-04-24 04:04:06 EDT
Restart of kded4 is quick and dirty but it's not solution and it seems that nearly all users are affected by this bug. But I have no glue too what's happening as it never appeared again...
Comment 5 Suren Karapetyan 2009-04-24 17:48:22 EDT
I ran strace on the crazy kded thread when that happened to me, but didn't save the logs.
All I remember is:
1. It was running "select" on a few fds
2. Then it tried to "read" from a fd which was a socket.
The always read failed with EAGAIN (not sure... maybe some other error :( )
Then it did the same thing again

Does it make sense to anyone?
Was anyone able to reproduce it without fresh F10 - update?
Comment 6 Gilboa Davara 2009-04-26 07:34:59 EDT
Seeing the same (including the select/read part) on each and every machine I upgrade to 4.2.2
Killing the kded4 process and restarting it by hand, solves the problem.

- Gilboa
Comment 7 Suren Karapetyan 2009-04-26 09:54:15 EDT
I hate this kind of bugs!
Just installed F10 on a VM,
logged in so it could create .kde folder.
Updated and guess what? Of course couldn't trigger it!

So a questions to those who have seen this bug:
Do you have kpackagekit and/or knetworkmanager installed?
I have both on both the systems I updated and got this bug
but I didn't install them today when trying to trigger this.

Comment 8 Jaroslav Reznik 2009-04-27 04:50:39 EDT
*** Bug 497765 has been marked as a duplicate of this bug. ***
Comment 9 Ngo Than 2009-04-27 05:17:15 EDT
i cannot reproduce the bug with F10-update. Does the bug show up with a fresh new user?
Comment 10 Lukáš Tinkl 2009-04-27 05:55:08 EDT
I can't reproduce either, even straight after the update.
Comment 11 Oliver Henshaw 2009-04-28 08:11:23 EDT
I saw this yesterday after upgrading to KDE 4.2.2. I managed to capture a backtrace and gather some info with ltrace, which I will attach. I also ran for a seconds with sysprof (re-building the rpms with the git version which can descend into kernel calls) to see where all the time is going.

As expected, the problem went away after a reboot.

NB: I realised at one point that I'd also updated libX11 during the same mammoth update on the 26th that pulled in kde 4.2.2, so I can't be absolutely sure this is the same kded4 problem. But it very much looks like it.

Relevant packages:
Comment 12 Oliver Henshaw 2009-04-28 08:13:13 EDT
Created attachment 341558 [details]
stacktrace gathered with gdb> thread apply all bt
Comment 13 Oliver Henshaw 2009-04-28 08:19:48 EDT
Created attachment 341560 [details]
result of ltrace -TSp

ltrace showed this group of calls, endlessly repeating. I couldn't detach ltrace with Ctrl+C, I had to SIGKILL it and then SIGCONT kded4.
Comment 14 Oliver Henshaw 2009-04-28 08:22:26 EDT
Created attachment 341561 [details]
sysprof profile gathered with the gnome-git version of sysprof
Comment 15 Kevin Kofler 2009-05-01 06:51:16 EDT
This looks a lot like some kind of deadlock/livelock.
Comment 16 Jaroslav Franek 2009-05-11 04:50:23 EDT
For a change this time when doing # yum update the kded4 crashed with signal 6 (Abort). After that another kded4 (replacement for the crashed one) started to hog the CPU badly.

I have the kded4 running at 100% of CPU right now, so if you have any suggestion on what to look at, please advise.

My theory is that there is a non-blocking access to a resource which is not available or marked as used (see the crash) included in an infinite loop. Under normal situation it may take few tries to get the resource, but something went wrong and the resource will not be available. Non-blocking access to a resource returns immediately EAGAIN and executing in an endless loop consumes 100% CPU.

KDE crash dump:

Application: KDE Daemon (kded4), signal SIGABRT
0x0000003b732a7f81 in nanosleep () from /lib64/libc.so.6
Current language:  auto; currently c
[Current thread is 1 (Thread 0x7f57d6187810 (LWP 3350))]

Thread 3 (Thread 0x7f57c534d950 (LWP 3830)):
#0  0x0000003b732dc886 in __poll (fds=0x11d9a80, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:87
#1  0x000000391983ae28 in g_main_context_poll () at gmain.c:3091
#2  g_main_context_iterate (context=0x11e60b0, block=1, dispatch=1, self=<value optimized out>) at gmain.c:2773
#3  0x000000391983b14b in IA__g_main_context_iteration (context=0x11e60b0, may_block=1) at gmain.c:2841
#4  0x000000391cd6cd3e in QEventDispatcherGlib::processEvents (this=0x1129830, flags=<value optimized out>) at kernel/qeventdispatcher_glib.cpp:325
#5  0x000000391cd41eb2 in QEventLoop::processEvents (this=<value optimized out>, flags=) at kernel/qeventloop.cpp:149
#6  0x000000391cd4227d in QEventLoop::exec (this=0x7f57c534cf60, flags=) at kernel/qeventloop.cpp:200
#7  0x000000391cc57738 in QThread::exec (this=<value optimized out>) at thread/qthread.cpp:481
#8  0x000000391cd25578 in QInotifyFileSystemWatcherEngine::run (this=0x122e650) at io/qfilesystemwatcher_inotify.cpp:214
#9  0x000000391cc5a6d2 in QThreadPrivate::start (arg=0x122e650) at thread/qthread_unix.cpp:189
#10 0x0000003b73e073da in start_thread (arg=<value optimized out>) at pthread_create.c:297
#11 0x0000003b732e62bd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112

Thread 2 (Thread 0x7f57c5d4e950 (LWP 4365)):
#0  0x0000003b732deaa2 in select () from /lib64/libc.so.6
#1  0x000000391cd21d66 in QProcessManager::run (this=0xe47370) at io/qprocess_unix.cpp:305
#2  0x000000391cc5a6d2 in QThreadPrivate::start (arg=0xe47370) at thread/qthread_unix.cpp:189
#3  0x0000003b73e073da in start_thread (arg=<value optimized out>) at pthread_create.c:297
#4  0x0000003b732e62bd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112

Thread 1 (Thread 0x7f57d6187810 (LWP 3350)):
[KCrash Handler]
#5  0x0000003b73232f05 in raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#6  0x0000003b73234a73 in abort () at abort.c:88
#7  0x0000003b7322bef9 in __assert_fail (assertion=0x3b814add48 "node->type == SND_CONFIG_TYPE_COMPOUND", file=0x3b814ae039 "conf.c", line=3190, function=0x3b814aeaf0 "snd_config_iterator_end")
    at assert.c:78
#8  0x0000003b8142d7a5 in ?? ()
#9  0x00000000011d8218 in ?? ()
#10 0x0000003b8143a169 in ?? ()
#11 0x0000000000000000 in ?? ()

For completeness the list of packages updated:

Dependencies Resolved

 Package                     Arch       Version              Repository             Size 
 PyQt4                       x86_64     4.4.4-6.fc10         updates               3.3 M 
 PyQt4-debuginfo             x86_64     4.4.4-6.fc10         updates-debuginfo      44 M 
 PyQt4-devel                 x86_64     4.4.4-6.fc10         updates               6.6 M 
 alsa-lib                    i386       1.0.20-1.fc10        updates               412 k 
 alsa-lib                    x86_64     1.0.20-1.fc10        updates               419 k 
 alsa-lib-debuginfo          x86_64     1.0.20-1.fc10        updates-debuginfo     1.3 M 
 alsa-lib-devel              x86_64     1.0.20-1.fc10        updates               998 k 
 e2fsprogs                   x86_64     1.41.4-5.fc10        updates               745 k 
 e2fsprogs-debuginfo         x86_64     1.41.4-5.fc10        updates-debuginfo     1.3 M 
 e2fsprogs-devel             x86_64     1.41.4-5.fc10        updates               764 k 
 e2fsprogs-libs              x86_64     1.41.4-5.fc10        updates               148 k 
 e2fsprogs-libs              i386       1.41.4-5.fc10        updates               152 k 
 elfutils                    x86_64     0.141-1.fc10         updates               227 k 
 elfutils-debuginfo          x86_64     0.141-1.fc10         updates-debuginfo     1.6 M 
 elfutils-devel              x86_64     0.141-1.fc10         updates                64 k 
 elfutils-libelf             x86_64     0.141-1.fc10         updates                56 k 
 elfutils-libelf-devel       x86_64     0.141-1.fc10         updates                26 k 
 elfutils-libs               x86_64     0.141-1.fc10         updates               193 k 
 gvfs                        x86_64     1.0.3-8.fc10         updates               1.1 M 
 gvfs-debuginfo              x86_64     1.0.3-8.fc10         updates-debuginfo     3.5 M 
 gvfs-fuse                   x86_64     1.0.3-8.fc10         updates                21 k 
 gvfs-obexftp                x86_64     1.0.3-8.fc10         updates                63 k 
 kchmviewer                  x86_64     4.0-4.fc10           updates               220 k 
 kchmviewer-debuginfo        x86_64     4.0-4.fc10           updates-debuginfo     1.4 M 
 kdegraphics                 x86_64     7:4.2.2-5.fc10       updates               3.4 M 
 kdegraphics-debuginfo       x86_64     7:4.2.2-5.fc10       updates-debuginfo      27 M 
 kdegraphics-devel           x86_64     7:4.2.2-5.fc10       updates                76 k 
 kdegraphics-libs            x86_64     7:4.2.2-5.fc10       updates               926 k 
 lcms                        x86_64     1.18-2.fc10          updates                81 k 
 lcms-debuginfo              x86_64     1.18-2.fc10          updates-debuginfo     821 k 
 lcms-libs                   x86_64     1.18-2.fc10          updates               108 k 
 lcms-libs                   i386       1.18-2.fc10          updates               109 k 
 libxcb                      x86_64     1.1.91-6.fc10        updates               120 k 
 libxcb                      i386       1.1.91-6.fc10        updates               124 k 
 libxcb-debuginfo            x86_64     1.1.91-6.fc10        updates-debuginfo     549 k 
 libxcb-devel                x86_64     1.1.91-6.fc10        updates               144 k 
 openssl                     i686       0.9.8g-13.fc10       updates               1.3 M 
 openssl                     x86_64     0.9.8g-13.fc10       updates               1.3 M 
 openssl-debuginfo           x86_64     0.9.8g-13.fc10       updates-debuginfo     3.2 M 
 openssl-devel               x86_64     0.9.8g-13.fc10       updates               1.9 M 
 phonon                      x86_64     4.3.1-4.fc10         updates               155 k 
 phonon-backend-xine         x86_64     4.3.1-4.fc10         updates               166 k 
 phonon-debuginfo            x86_64     4.3.1-4.fc10         updates-debuginfo     4.8 M 
 phonon-devel                x86_64     4.3.1-4.fc10         updates                63 k 
 selinux-policy              noarch     3.5.13-58.fc10       updates               626 k 
 selinux-policy-mls          noarch     3.5.13-58.fc10       updates               1.3 M 
 selinux-policy-targeted     noarch     3.5.13-58.fc10       updates               2.1 M 
 unique                      x86_64     1.0.8-1.fc10         updates                49 k 
 unique-debuginfo            x86_64     1.0.8-1.fc10         updates-debuginfo      84 k 
Installing for dependencies:                                                             
 kio_msits                   x86_64     7:4.2.2-5.fc10       updates                19 k 

Transaction Summary
Install      1 Package(s)                                                                
Update      49 Package(s)                                                                
Remove       0 Package(s)
Comment 17 Suren Karapetyan 2009-05-11 06:45:24 EDT
I think it makes sense to backup ~/.kde folder *before* the update.
Then once again after first restart (when kded4 starts eating cpu).
And compare with the data you get when kded4 starts to run normally.
Comment 18 Steven M. Parrish 2009-05-30 22:30:59 EDT
Since this has been reported upstream I am going to close this report.  We will monitor the upstream report for a fix.

Note You need to log in before you can comment on or make changes to this bug.