Bug 268038

Summary: kded4 eating 100% cpu - ntrack related
Product: [Unmaintained] Network Management Reporter: Arkadiusz Miskiewicz <arekm>
Component: KDED ModuleAssignee: Will Stephenson <wstephenson>
Status: RESOLVED UPSTREAM    
Severity: normal CC: alex.merry, amg1127, arthur, bernardo, depetrini, doochik, ismail, jens, kde20091215.20.mlaker, kde, koepke, kretz, mieszcz, null, rm, rsimmons0, rtkluttz, sergiu, stephan.diestelhorst, stuffcorpse, wengxt, werehuman, zorael
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: Unlisted Binaries   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description Arkadiusz Miskiewicz 2011-03-09 08:36:37 UTC
Version:           unspecified (using KDE 4.6.1) 
OS:                Linux

My kded4 eats 100% cpu. Backtrace shows:
[...]
Loaded symbols for /usr/lib64/kde4/powerdevildpmsaction.so
0x00007f1185ade43b in rtnl_link_get_ifindex () from /usr/lib64/libnl.so.1
(gdb) bt
#0  0x00007f1185ade43b in rtnl_link_get_ifindex () from /usr/lib64/libnl.so.1
#1  0x00007f1185d0c480 in ?? () from /usr/lib64/ntrack/modules/ntrack-libnl1.so
#2  0x00007f1185d0ca4d in _ntrack_arch_process_data () from /usr/lib64/ntrack/modules/ntrack-libnl1.so
#3  0x00007f1186118f6b in QNtrack::socketActivated(int) () from /usr/lib64/libntrack-qt4.so.1
#4  0x00007f118611928a in QNtrack::qt_metacall(QMetaObject::Call, int, void**) () from /usr/lib64/libntrack-qt4.so.1
#5  0x00007f119a92f45f in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) () from /usr/lib64/libQtCore.so.4
#6  0x00007f119a9782fe in QSocketNotifier::activated(int) () from /usr/lib64/libQtCore.so.4
#7  0x00007f119a935b1b in QSocketNotifier::event(QEvent*) () from /usr/lib64/libQtCore.so.4
#8  0x00007f1199ac59a4 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib64/libQtGui.so.4
#9  0x00007f1199aca54a in QApplication::notify(QObject*, QEvent*) () from /usr/lib64/libQtGui.so.4
#10 0x00007f119b6da886 in KApplication::notify (this=0x7fff5b3c9260, receiver=0x1a78c00, event=0x7fff5b3c8f70)
    at /usr/src/debug/kdelibs-4.6.1/kdeui/kernel/kapplication.cpp:311
#11 0x00007f119a91ac5c in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib64/libQtCore.so.4
#12 0x00007f119a945ea9 in ?? () from /usr/lib64/libQtCore.so.4
#13 0x00007f11967c2ca3 in g_main_context_dispatch () from /usr/lib64/libglib-2.0.so.0
#14 0x00007f11967c3480 in ?? () from /usr/lib64/libglib-2.0.so.0
#15 0x00007f11967c371d in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0
#16 0x00007f119a946506 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQtCore.so.4
#17 0x00007f1199b6ac5e in ?? () from /usr/lib64/libQtGui.so.4
#18 0x00007f119a91a002 in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQtCore.so.4
#19 0x00007f119a91a244 in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib64/libQtCore.so.4
#20 0x00007f119a91e71f in QCoreApplication::exec() () from /usr/lib64/libQtCore.so.4
#21 0x00007f118e4a4497 in kdemain (argc=1, argv=0x18c4ac0) at /usr/src/debug/kdelibs-4.6.1/kded/kded.cpp:925
#22 0x0000000000406c48 in launch (argc=1, _name=0x40afdf "kded4", args=<value optimized out>, cwd=0x0, envc=<value optimized out>,
    envs=<value optimized out>, reset_env=false, tty=0x0, avoid_loops=false, startup_id_str=0x40ae29 "0")
    at /usr/src/debug/kdelibs-4.6.1/kinit/kinit.cpp:734
#23 0x00000000004094c6 in main (argc=2, argv=0x7fff5b3ca198, envp=0x7fff5b3ca1b0) at /usr/src/debug/kdelibs-4.6.1/kinit/kinit.cpp:1849
(gdb)


Reproducible: Sometimes

Steps to Reproduce:
Unknown. It just happens sometimes.
Comment 1 Alex Merry 2011-04-07 15:07:23 UTC
I got this occasionally with NTrack 013 installed.  I now run the latest ntrack from bzr (mainly because I wanted debug info to try and track this down a bit better), but haven't had the problem again so far.  But it's only been a couple of days.
Comment 2 Arkadiusz Miskiewicz 2011-04-07 15:22:46 UTC
For me the problem happens when I restart laptop from scratch (ntrack 0.14 here). Then I kill kded4, start it again and problem doesn't come back. Reboot - problem happens again.
Comment 3 Alex Merry 2011-04-07 23:06:10 UTC
(In reply to comment #2)
> For me the problem happens when I restart laptop from scratch (ntrack 0.14
> here). Then I kill kded4, start it again and problem doesn't come back. Reboot
> - problem happens again.

What happens if you kill it and restart it with `kdeinit4_wrapper kded4`?
Comment 4 Alex Merry 2011-04-07 23:17:25 UTC
I now appear to have stopped getting this problem (involving NTrack), and get bug 220047 instead (which happens even if I stop all the kded services).
Comment 5 Alex Merry 2011-04-07 23:34:46 UTC
Commenting out the line
  new NtrackNetworkState( this );
in kde-workspace/solid-networkstatus/kded/networkstatus.cpp fixes this problem for me completely.
Comment 6 Alex Merry 2011-04-07 23:50:30 UTC
A bit of debugging code shows that QNtrack::socketActivated is called continuously.
Comment 7 Alex Merry 2011-04-08 03:00:25 UTC
Also, QNtrack is watching fd 0.  I can't reproduce this behaviour in a test program, even if I call close(0) just before QNtrack::instance.  But it seems to be happening in kded4 when started from kdeinit4.
Comment 8 Weng Xuetian 2011-04-08 07:38:18 UTC
A simple way for reproduce:
Use archlinux and kdeplasma-applets-networkmanagement
1. Connect a pptp VPN
2. Disconnect it.
Then kded4 got 100% cpu.

Using ntrack-013 here. Since 014 has a link problem, archlinux just downgrade it, but seems it's not solved with 014.

Backtrace:
#0  0x00007f370440f5f4 in rtnl_link_get_ifindex () from /usr/lib/libnl.so.1
#1  0x00007f370463d51e in ?? () from /usr/lib/ntrack/modules/ntrack-libnl1.so
#2  0x00007f370463d7cd in _ntrack_arch_process_data () from /usr/lib/ntrack/modules/ntrack-libnl1.so
#3  0x00007f3704a47f2b in QNtrack::socketActivated(int) () from /usr/lib/libntrack-qt4.so.1
#4  0x00007f3704a4828a in QNtrack::qt_metacall(QMetaObject::Call, int, void**) () from /usr/lib/libntrack-qt4.so.1
#5  0x00007f371321be0f in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) () from /usr/lib/libQtCore.so.4
#6  0x00007f371326386e in QSocketNotifier::activated(int) () from /usr/lib/libQtCore.so.4
#7  0x00007f371322180b in QSocketNotifier::event(QEvent*) () from /usr/lib/libQtCore.so.4
#8  0x00007f3713e3d6a4 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/libQtGui.so.4
#9  0x00007f3713e4226a in QApplication::notify(QObject*, QEvent*) () from /usr/lib/libQtGui.so.4
#10 0x00007f3714b5bd36 in KApplication::notify(QObject*, QEvent*) () from /usr/lib/libkdeui.so.5
#11 0x00007f371320690c in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib/libQtCore.so.4
#12 0x00007f37132313c9 in ?? () from /usr/lib/libQtCore.so.4
#13 0x00007f3710974bf3 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#14 0x00007f37109753d0 in ?? () from /usr/lib/libglib-2.0.so.0
#15 0x00007f371097566d in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#16 0x00007f3713231a0f in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
#17 0x00007f3713ee303e in ?? () from /usr/lib/libQtGui.so.4
#18 0x00007f3713205ca2 in QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
#19 0x00007f3713205eec in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/libQtCore.so.4
#20 0x00007f371320a3eb in QCoreApplication::exec() () from /usr/lib/libQtCore.so.4
#21 0x00007f3715626047 in kdemain () from /usr/lib/libkdeinit4_kded4.so
#22 0x00007f37152dbdcd in __libc_start_main () from /lib/libc.so.6
#23 0x00000000004005c9 in _start ()
Comment 9 Sergiu Bivol 2011-04-09 08:27:25 UTC
(In reply to comment #8)
> A simple way for reproduce:
> Use archlinux and kdeplasma-applets-networkmanagement
> 1. Connect a pptp VPN
> 2. Disconnect it.
> Then kded4 got 100% cpu.

I can confirm the same behaviour on KDE 4.6.2, Kubuntu 11.04. It used to work fine in KDE 4.5.9 (the Beta versions).
Comment 10 Weng Xuetian 2011-04-12 02:49:37 UTC
I raised a bug report for ntrack, 
https://bugs.launchpad.net/ntrack/+bug/755608

But I wonder ntrack is already used for a long time (since early 4.6) and the ntrack code in that problemistic function didn't change since it came to Archlinux... I don't know whether my patch for ntrack is correct or not, or it should be a kded problem.
Comment 11 Alex Merry 2011-04-12 12:28:44 UTC
It might be worth checking whether this happens with older versions of NTrack.  I'm fairly sure I didn't get this with NTrack 008, for example.

Also, there seem to be two different problems here.  There is the PPTP issue that you've reported upstream, and the issue I've been getting where libnl returns fd 0 for polling, and poll() always returns immediately with POLLHUP on that fd.
Comment 12 Matthias Kretz 2011-05-16 08:26:16 UTC
I just looked at a hang in my kded4 and it seems that ntrack doesn't even leave frame #1. Might be gdb not able to catch it, though. I can investigate again once it is back hanging:

Thread 1 (Thread 0x7ff0acb21780 (LWP 5840)):
#0  0x00007ff0888f8078 in rtnl_link_get_ifindex@plt () from /usr/lib/ntrack/modules/ntrack-libnl1.so
#1  0x00007ff0888f84c0 in ?? () from /usr/lib/ntrack/modules/ntrack-libnl1.so
#2  0x00007ff0888f8a9d in _ntrack_arch_process_data () from /usr/lib/ntrack/modules/ntrack-libnl1.so
#3  0x00007ff088d04ecb in QNtrack::socketActivated(int) () from /usr/lib/libntrack-qt4.so.1
#4  0x00007ff088d0522a in QNtrack::qt_metacall(QMetaObject::Call, int, void**) () from /usr/lib/libntrack-qt4.so.1
#5  0x00007ff0ab7bc5f8 in QMetaObject::activate (sender=0x1ee1880, m=<value optimized out>, local_signal_index=<value optimized out>, argv=0x7fff0a08a6a0) at kernel/qobject.cpp:3287
#6  0x00007ff0ab803b7e in QSocketNotifier::activated (this=<value optimized out>, _t1=31) at .moc/release-shared/moc_qsocketnotifier.cpp:89
#7  0x00007ff0ab7c1f4b in QSocketNotifier::event (this=0x1ee1880, e=0x7fff0a08ad30) at kernel/qsocketnotifier.cpp:317
#8  0x00007ff0aab689e4 in QApplicationPrivate::notify_helper (this=0x1d20380, receiver=0x1ee1880, e=0x7fff0a08ad30) at kernel/qapplication.cpp:4462
#9  0x00007ff0aab6d3aa in QApplication::notify (this=<value optimized out>, receiver=0x1ee1880, e=0x7fff0a08ad30) at kernel/qapplication.cpp:4341
#10 0x00007ff0ac522866 in KApplication::notify (this=0x7fff0a08afd0, receiver=0x1ee1880, event=0x7fff0a08ad30) at ../../kdeui/kernel/kapplication.cpp:311
#11 0x00007ff0ab7a749c in QCoreApplication::notifyInternal (this=0x7fff0a08afd0, receiver=0x1ee1880, event=0x7fff0a08ad30) at kernel/qcoreapplication.cpp:731
#12 0x00007ff0ab7d1da9 in sendEvent (source=0x1d23fb0) at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:215
#13 socketNotifierSourceDispatch (source=0x1d23fb0) at kernel/qeventdispatcher_glib.cpp:110
#14 0x00007ff0a7804bcd in g_main_dispatch (context=0x1d22d50) at /build/buildd/glib2.0-2.28.6/./glib/gmain.c:2440
#15 g_main_context_dispatch (context=0x1d22d50) at /build/buildd/glib2.0-2.28.6/./glib/gmain.c:3013
#16 0x00007ff0a78053a8 in g_main_context_iterate (context=0x1d22d50, block=<value optimized out>, dispatch=1, self=<value optimized out>) at /build/buildd/glib2.0-2.28.6/./glib/gmain.c:3091
#17 0x00007ff0a7805639 in g_main_context_iteration (context=0x1d22d50, may_block=1) at /build/buildd/glib2.0-2.28.6/./glib/gmain.c:3154
#18 0x00007ff0ab7d23ef in QEventDispatcherGlib::processEvents (this=0x1bc2ce0, flags=<value optimized out>) at kernel/qeventdispatcher_glib.cpp:422
#19 0x00007ff0aac0fdfe in QGuiEventDispatcherGlib::processEvents (this=<value optimized out>, flags=<value optimized out>) at kernel/qguieventdispatcher_glib.cpp:204
#20 0x00007ff0ab7a6882 in QEventLoop::processEvents (this=<value optimized out>, flags=...) at kernel/qeventloop.cpp:149
#21 0x00007ff0ab7a6abc in QEventLoop::exec (this=0x7fff0a08af60, flags=...) at kernel/qeventloop.cpp:201
#22 0x00007ff0ab7aaecb in QCoreApplication::exec () at kernel/qcoreapplication.cpp:1008
#23 0x00007ff09a781135 in kdemain (argc=1, argv=0x1c19cd0) at ../../kded/kded.cpp:925
#24 0x0000000000406dd3 in launch (argc=1, _name=0x40b2d7 "kded4", args=<value optimized out>, cwd=0x0, envc=<value optimized out>, envs=<value optimized out>, reset_env=false, tty=0x0, avoid_loops=false, startup_id_str=0x40b15e "0") at ../../kinit/kinit.cpp:746
#25 0x00000000004098fe in main (argc=4, argv=0x7fff0a08c0e8, envp=0x7fff0a08c110) at ../../kinit/kinit.cpp:1861
(gdb) fin
Run till exit from #0  0x00007ff0888f8078 in rtnl_link_get_ifindex@plt () from /usr/lib/ntrack/modules/ntrack-libnl1.so
0x00007ff0888f84c0 in ?? () from /usr/lib/ntrack/modules/ntrack-libnl1.so
(gdb)
Run till exit from #0  0x00007ff0888f84c0 in ?? () from /usr/lib/ntrack/modules/ntrack-libnl1.so
[############# Here I was waiting for several minutes ##############]
^C
Program received signal SIGINT, Interrupt.
0x00007ff0888f8078 in rtnl_link_get_ifindex@plt () from /usr/lib/ntrack/modules/ntrack-libnl1.so
(gdb) quit
Comment 13 Lamarque V. Souza 2011-05-17 01:37:09 UTC
*** Bug 270152 has been marked as a duplicate of this bug. ***
Comment 14 Lamarque V. Souza 2011-05-17 01:39:27 UTC
*** Bug 272527 has been marked as a duplicate of this bug. ***
Comment 15 Scott Kitterman 2011-05-17 20:20:38 UTC
This is an ntrack bug.  I've just fixed it for Kubuntu Oneiric and have a pending post-release update for Natty (11.04).  For other distros:

http://launchpadlibrarian.net/71887685/ntrack_011-1ubuntu1_011-1ubuntu2.diff.gz

This should be closed in b.k.o.
Comment 16 Alex Merry 2011-05-18 02:23:10 UTC
Resolving as UPSTREAM, since it's an Ntrack bug.

Note that the fix is not in a released version of Ntrack yet, but may be backported into distro packages (eg: Ubuntu).
Comment 17 Alex Merry 2011-05-19 01:31:07 UTC
I should note that the latest ntrack (ie: revision 312, which includes the patch in comment #15) doesn't actually fix the problem for me.
Comment 18 Alex Merry 2011-05-19 14:00:57 UTC
For those interested, this is the problem I've been having: http://bugs.launchpad.net/ntrack/+bug/785119
Comment 19 Alexey Androsov 2011-05-19 14:07:09 UTC
(In reply to comment #18)
> For those interested, this is the problem I've been having:
> http://bugs.launchpad.net/ntrack/+bug/785119

maybe it's relative to https://bugs.launchpad.net/ntrack/+bug/755608
Comment 20 Alex Merry 2011-05-19 15:01:43 UTC
OK, so there are two issues conflated in this bug report.

There's the VPN thing where an infinite loop is hit within ntrack.  That is reported upstream at https://bugs.launchpad.net/ntrack/+bug/755608

Then there's the problem I was having (I don't even use a VPN) where poll() in the main loop never blocks because ntrack is trying to use fd 0, because it couldn't load the libnl module, and in kded4, fd 0 was a socket where the other end was closed (or something like that).  It's a comination of http://bugs.launchpad.net/ntrack/+bug/785119 and http://bugs.launchpad.net/ntrack/+bug/785153
Comment 21 Lamarque V. Souza 2011-05-20 18:00:17 UTC
*** Bug 273740 has been marked as a duplicate of this bug. ***
Comment 22 jose bernardo silva 2011-05-22 21:29:44 UTC
With the ntrack in natty-proposed, I now get some kded4 "suicides", where kded4 simply quits and I have to launch it again. I haven't got a dump or a drkonqui output, as I never get one. I just notice that my wifi connection has disappeared, and when I do a ps kded4 is no longer present. At least it is better than the previous situation, where it went to 100% cpu on vpn/3G disconnections.
Comment 23 Alex Merry 2011-05-23 02:26:21 UTC
(In reply to comment #22)
> With the ntrack in natty-proposed, I now get some kded4 "suicides", where kded4
> simply quits and I have to launch it again. I haven't got a dump or a drkonqui
> output, as I never get one. I just notice that my wifi connection has
> disappeared, and when I do a ps kded4 is no longer present. At least it is
> better than the previous situation, where it went to 100% cpu on vpn/3G
> disconnections.

If you can attach gdb to kded4 before it crashes:
gdb --pid $(pidof kded4)
(you'll also need to give gdb the "cont" command to get kded4 to continue executing), then see what happens when it quits (giving the "thread apply all bt" command to gdb would be useful), that would be really helpful.
Comment 24 Christoph Feck 2011-05-31 12:36:36 UTC
*** Bug 274578 has been marked as a duplicate of this bug. ***
Comment 25 Christoph Feck 2011-06-06 15:27:52 UTC
*** Bug 274812 has been marked as a duplicate of this bug. ***
Comment 26 Robert Simmons 2011-06-08 00:25:57 UTC
The fix for this problem just appeared in Kubuntu's updates.  After installing the new set of ntrack packages, I can confirm that the problem has been fixed.

I am using Kubuntu 11.04, KDE 4.6.3 and the following ntrack packages were update to these versions:
ntrack-module-libnl-0     011-1ubuntu1.1
libntrack0                011-1ubuntu1.1
libntrack-qt4-1           011-1ubuntu1.1
Comment 27 Ralph Moenchmeyer 2011-08-15 14:11:57 UTC
For me the problem is not fixed at all. Instead it came up after one of my latest upgrades for KDE 4.7.

I am running Opensuse 11.4 with KDE 4.7. Everything with KDE 4.7 went smoothly until my latest KDE 4.7 update (today) via the Opensuse KDE Factory Repository.   

When I go from 

kdebase4-runtime version 4.7.0-8.1 in Opensuses's KDE Factory repository to    
kdebase4-runtime version 4.7.0-302 in Opensuses's KDE Factory repository 

the following new libs are automatically installed because of dependencies: 

libntrack-qt4-1 version 014-4.1
libntrack0 version 014-4.1
ntrack-libnl1 version 014-4.1

With these libraries kded4 runs amok: 100% cpu load on one processor core. So for me it is a new ntrack problem, whic I did not experience before. 

Switching back to an older kdebase4-runtime version where the dependency on the ntrack libs is not given solves the kded4 problem at once. 

So please check for ntrack errors related to the latest KDE 4.7 versions. 

I think this bug should definitely be reopened.
Comment 28 Alex Merry 2011-08-15 14:41:21 UTC
(In reply to comment #27)
> libntrack-qt4-1 version 014-4.1
> libntrack0 version 014-4.1
> ntrack-libnl1 version 014-4.1

ntrack 014 has a known issue that causes this infinite loop (https://bugs.launchpad.net/ntrack/+bug/755608).  It will be fixed in ntrack 015.

> I think this bug should definitely be reopened.

Why?  The bug is in ntrack, not KDE, and will be fixed in the next released version of ntrack.  The only way to get the fix faster would be to convince openSUSE to backport the fix, or to disable ntrack support in kde-runtime.
Comment 29 Ismail Donmez 2011-08-15 14:48:35 UTC
I fixed the ntrack package for openSUSE. Thanks.
Comment 30 Unknown 2011-08-25 12:34:06 UTC
*** Bug 280331 has been marked as a duplicate of this bug. ***
Comment 31 Christoph Feck 2011-10-28 11:19:58 UTC
*** Bug 220047 has been marked as a duplicate of this bug. ***
Comment 32 Lamarque V. Souza 2012-03-29 14:45:12 UTC
*** Bug 297035 has been marked as a duplicate of this bug. ***