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 PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 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): kdelibs-4.2.2-7.fc10.x86_64 How reproducible: Upgraded to kde-4.2.2 through yum update, restarted the system Steps to Reproduce: 1. 2. 3. Actual results: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 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.
$ 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 Continuing. ^C 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
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.
(PS: My main desktop is F9 i386.)
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...
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?
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
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. Suren
*** Bug 497765 has been marked as a duplicate of this bug. ***
i cannot reproduce the bug with F10-update. Does the bug show up with a fresh new user?
I can't reproduce either, even straight after the update.
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: libX11-1.1.5-3.fc10.i386 kdelibs-4.2.2-7.fc10.i386
Created attachment 341558 [details] stacktrace gathered with gdb> thread apply all bt
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.
Created attachment 341561 [details] sysprof profile gathered with the gnome-git version of sysprof
This looks a lot like some kind of deadlock/livelock.
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 ========================================================================================= Updating: 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)
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.
Since this has been reported upstream I am going to close this report. We will monitor the upstream report for a fix.