Bug 268038

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.

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.

(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`?

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).

Commenting out the line
  new NtrackNetworkState( this );
in kde-workspace/solid-networkstatus/kded/networkstatus.cpp fixes this problem for me completely.

A bit of debugging code shows that QNtrack::socketActivated is called continuously.

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.

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 ()

(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).

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.

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.

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

*** Bug 270152 has been marked as a duplicate of this bug. ***

*** Bug 272527 has been marked as a duplicate of this bug. ***

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.

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).

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.

For those interested, this is the problem I've been having: http://bugs.launchpad.net/ntrack/+bug/785119

(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

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

*** Bug 273740 has been marked as a duplicate of this bug. ***

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.

(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.

*** Bug 274578 has been marked as a duplicate of this bug. ***

*** Bug 274812 has been marked as a duplicate of this bug. ***

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

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.

(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.

I fixed the ntrack package for openSUSE. Thanks.

*** Bug 280331 has been marked as a duplicate of this bug. ***

*** Bug 220047 has been marked as a duplicate of this bug. ***

*** Bug 297035 has been marked as a duplicate of this bug. ***