knotify4 uses 100% CPU despite not Qt/Kde apps being in-use

Bug #736453 reported by Paul Sladen on 2011-03-16
34
This bug affects 6 people
Affects Status Importance Assigned to Milestone
KDE Base
Invalid
High
kdebase-runtime (Ubuntu)
Undecided
Unassigned

Bug Description

Binary package hint: kdebase-runtime

  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
 7387 sladen 20 0 82728 11m 9296 S 100 0.4 14:54.14 knotify4

Fresh logout+login. 'knotify4' using 100% CPU. What do I need to look for?

DistroRelease: Ubuntu 11.04
Package: kdebase-runtime 4:4.6.1-0ubuntu1
ExecutablePath: /usr/bin/knotify4

Paul Sladen (sladen) wrote :
Paul Sladen (sladen) on 2011-03-16
description: updated
Paul Sladen (sladen) wrote :
Download full text (4.5 KiB)

http://forums.opensuse.org/applications/415387-knotify4-consuming-100-cpu.html

gdb -p ...
(gdb) thread apply all bt
Thread 2 (Thread 0xb56c1b70 (LWP 7392)):
#0 0x00449416 in __kernel_vsyscall ()
#1 0x0090ee06 in poll () from /lib/libc.so.6
#2 0x0262f97b in g_qsort_with_data (pbase=0xb4d01480, total_elems=2, size=4294967295, compare_func=0xb4d01480, user_data=0x2)
    at /build/buildd/glib2.0-2.28.3/./glib/gqsort.c:158
#3 0x0261f2df in g_main_context_iterate (context=0x8405934, block=40040784, dispatch=1, self=<value optimised out>)
    at /build/buildd/glib2.0-2.28.3/./glib/gmain.c:3076
#4 0x0261f654 in g_main_loop_ref (loop=0x8405930) at /build/buildd/glib2.0-2.28.3/./glib/gmain.c:3200
#5 0x015c954c in QEventDispatcherGlib::processEvents (this=0x83fb8b0, flags=...) at kernel/qeventdispatcher_glib.cpp:422
#6 0x0159b299 in QEventLoop::processEvents (this=0xb56c1290, flags=...) at kernel/qeventloop.cpp:149
#7 0x0159b532 in QEventLoop::exec (this=0xb56c1290, flags=...) at kernel/qeventloop.cpp:201
#8 0x014a52a0 in QThread::exec (this=0x84049e8) at thread/qthread.cpp:492
#9 0x0157cfeb in QInotifyFileSystemWatcherEngine::run (this=0x84049e8) at io/qfilesystemwatcher_inotify.cpp:248
#10 0x014a7da2 in QThreadPrivate::start (arg=0x84049e8) at thread/qthread_unix.cpp:320
#11 0x05a08e99 in start_thread () from /lib/libpthread.so.0
#12 0x0091d5ce in clone () from /lib/libc.so.6

Thread 1 (Thread 0xb77a7ac0 (LWP 7387)):
#0 0x00449416 in __kernel_vsyscall ()
#1 0x05a0d48c in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
#2 0x0092b28d in pthread_cond_wait () from /lib/libc.so.6
#3 0x014a8467 in wait (this=0x84044e8, mutex=0x84044d0, time=4294967295) at thread/qwaitcondition_unix.cpp:88
#4 QWaitCondition::wait (this=0x84044e8, mutex=0x84044d0, time=4294967295) at thread/qwaitcondition_unix.cpp:160
#5 0x014a74cf in QThread::wait (this=0x84049e8, time=4294967295) at thread/qthread_unix.cpp:722
#6 0x0156fc87 in QFileSystemWatcher::~QFileSystemWatcher (this=0x83fa888, __in_chrg=<value optimised out>) at io/qfilesystemwatcher.cpp:446
#7 0x0156fd52 in QFileSystemWatcher::~QFileSystemWatcher (this=0x83fa888, __in_chrg=<value optimised out>) at io/qfilesystemwatcher.cpp:462
#8 0x015afb97 in QObjectPrivate::deleteChildren (this=0x8404910) at kernel/qobject.cpp:1964
#9 0x015b43af in QObject::~QObject (this=0x8404398, __in_chrg=<value optimised out>) at kernel/qobject.cpp:946
#10 0x00204e5b in Solid::Backends::Fstab::FstabWatcher::~FstabWatcher (this=0x8404398, __in_chrg=<value optimised out>)
    at ../../../solid/solid/backends/fstab/fstabwatcher.cpp:48
#11 0x00204e92 in Solid::Backends::Fstab::FstabWatcher::~FstabWatcher (this=0x8404398, __in_chrg=<value optimised out>)
    at ../../../solid/solid/backends/fstab/fstabwatcher.cpp:51
#12 0x00204d05 in destroy () at ../../../solid/solid/backends/fstab/fstabwatcher.cpp:30
#13 0x0018dfbb in Solid::CleanUpGlobalStatic::~CleanUpGlobalStatic (this=0x2218c8, __in_chrg=<value optimised out>)
    at ../../../solid/solid/soliddefs_p.h:67
#14 0x0087ca1f in ?? () from /lib/libc.so.6
#15 0x0087ca7f in exit () from /lib/libc.so.6
#16 0x00b6cd8b in ?? () from /usr/lib/libQtGui.so.4
#17 0x0068311a ...

Read more...

MMlosh (mmlosh) wrote :

I don't use kde, but I have some QT apps.. which pull phonon, kdebase, and knotify as well.

This never happened before.
But I have a possible clue --- stopped (pulseaudio -k) and started(pulseaudio --start --log-taget=syslog) the pulseaudio server, because it was failing to notice new audio devices

Was that caused by some sort of phonon's "new audio device found" message or something?

MMlosh (mmlosh) wrote :

(But I upgraded to natty yesterday, so there are too many factors)
I remember deinstalling KWin, thought

Changed in kdebase:
importance: Unknown → High
status: Unknown → Invalid
Changed in kdebase-runtime (Ubuntu):
status: New → Confirmed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.