Version: (using KDE Devel) Installed from: Compiled sources OS: Linux When I start kde4 knotify crashes, which is not an issue since kde4 is still beta. however it triggers >10 other instances of knotify resulting in >10 drkonqi windows. If I click on anything, e.g. kmenu or some other item on the desktop another bunch of knotify crashes occur. Although I have the debuginfo packages installed for kdebase there is no usable backtrace. So there seems to be an issue that knotify is started over and over again although it crashed which results in a loop preventing the user to access the desktop. Expected behaviour: After crashing twice in a row, stop triggering knotify and tell the user how he can re-enable it, if the issue is solved. The kdebase package I use has 3.92.0.svn703920-52.1 as version number.
Do you have a backtrace ? I can't reproduce the problem here. (Note that I just tried this week, not previous week, and i noticed some problem to run knotify4 related to phonon)
drkonqi tells me that the backtrace is of no use, although I have the debuginfo-packages installed. As I said, the problem is not that knotify crashes, but that it is restarted again and again. What bit of KDE restarts knotify and does it recognise when it crashes, i.e. stops after trying x times?
I just started the KDE-Four-Live.i686-0.6.1.iso inside virtualbox and after clicking a bit around (I think it appeared when I started korganizer, but I'm not sure because I clicked on several things and things took long to start), I got the following backtrace: debugging symbols found) Using host libthread_db library "/lib/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread 0xb6abb6d0 (LWP 3280)] [New Thread 0xae31bb90 (LWP 3332)] [New Thread 0xaeb1cb90 (LWP 3331)] [New Thread 0xaf4eab90 (LWP 3330)] [New Thread 0xb08d5b90 (LWP 3327)] [New Thread 0xb10d6b90 (LWP 3326)] [New Thread 0xb1aa4b90 (LWP 3325)] [New Thread 0xb268eb90 (LWP 3324)] [New Thread 0xb329ab90 (LWP 3323)] [New Thread 0xb3addb90 (LWP 3322)] [New Thread 0xb42deb90 (LWP 3321)] 0xffffe402 in __kernel_vsyscall () [Current thread is 0 (LWP 3280)] Thread 11 (Thread 0xb42deb90 (LWP 3321)): #0 0xffffe402 in __kernel_vsyscall () #1 0xb7dfb7ec in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0xb4e25b95 in metronom_sync_loop () from /usr/lib/libxine.so.1 Thread 10 (Thread 0xb3addb90 (LWP 3322)): #0 0xffffe402 in __kernel_vsyscall () #1 0xb7dff05b in waitpid () from /lib/libpthread.so.0 #2 0xb729879f in ?? () from /usr/lib/libkdeui.so.5 #3 0x00000d0e in ?? () #4 0x00000000 in ?? () Thread 9 (Thread 0xb329ab90 (LWP 3323)): #0 0xffffe402 in __kernel_vsyscall () #1 0xb7dfb566 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0xb4e34f3a in fifo_remove_int () from /usr/lib/libxine.so.1 #3 0xb4e61ff4 in ?? () from /usr/lib/libxine.so.1 Thread 8 (Thread 0xb268eb90 (LWP 3324)): #0 0xffffe402 in __kernel_vsyscall () #1 0xb7dfb7ec in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0xb4e33ce8 in video_out_loop () from /usr/lib/libxine.so.1 #3 0x00000000 in ?? () Thread 7 (Thread 0xb1aa4b90 (LWP 3325)): #0 0xffffe402 in __kernel_vsyscall () #1 0xb7dfb566 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0xb4e29394 in fifo_buffer_get () from /usr/lib/libxine.so.1 #3 0x00000001 in ?? () #4 0x00000000 in ?? () Thread 6 (Thread 0xb10d6b90 (LWP 3326)): #0 0xffffe402 in __kernel_vsyscall () #1 0xb7dfb566 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0xb4e29394 in fifo_buffer_get () from /usr/lib/libxine.so.1 #3 0x00000001 in ?? () Thread 5 (Thread 0xb08d5b90 (LWP 3327)): #0 0xffffe402 in __kernel_vsyscall () #1 0xb7dfb566 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0xb4e3a1e8 in xine_event_wait () from /usr/lib/libxine.so.1 #3 0x0876ddf0 in ?? () #4 0x0870b820 in ?? () #5 0x00000001 in ?? () #6 0xb4e3a27c in listener_loop () from /usr/lib/libxine.so.1 #7 0x0876ddf0 in ?? () #8 0x00000000 in ?? () Thread 4 (Thread 0xaf4eab90 (LWP 3330)): #0 0xffffe402 in __kernel_vsyscall () #1 0xb7dfb566 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0xb4e29394 in fifo_buffer_get () from /usr/lib/libxine.so.1 #3 0x00000001 in ?? () #4 0x00000000 in ?? () Thread 3 (Thread 0xaeb1cb90 (LWP 3331)): #0 0xffffe402 in __kernel_vsyscall () #1 0xb7dfb566 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0xb4e29394 in fifo_buffer_get () from /usr/lib/libxine.so.1 #3 0x00000001 in ?? () Thread 2 (Thread 0xae31bb90 (LWP 3332)): #0 0xffffe402 in __kernel_vsyscall () #1 0xb7dfb566 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0xb4e3a1e8 in xine_event_wait () from /usr/lib/libxine.so.1 #3 0x0876e5f8 in ?? () #4 0x087605b8 in ?? () #5 0x00000001 in ?? () #6 0xb4e3a27c in listener_loop () from /usr/lib/libxine.so.1 #7 0x0876e5f8 in ?? () #8 0x00000000 in ?? () Thread 1 (Thread 0xb6abb6d0 (LWP 3280)): #0 0xffffe402 in __kernel_vsyscall () #1 0xb7dfb566 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0xb7e646e5 in QMutexPrivate::wait () from /usr/lib/libQtCore.so.4 #3 0xb7e61289 in QMutex::lock () from /usr/lib/libQtCore.so.4 #4 0xb4e7c8e8 in ?? () from /usr/lib/kde4/phonon_xine.so #5 0x0872fd0c in ?? () #6 0xb6e0f140 in ?? () from /lib/libc.so.6 #7 0x08710a58 in ?? () #8 0xb4e890c3 in ?? () from /usr/lib/kde4/phonon_xine.so #9 0xb6d47179 in free () from /lib/libc.so.6 #10 0xb4e8b979 in ?? () from /usr/lib/kde4/phonon_xine.so #11 0x0872fce0 in ?? () #12 0xb703bff4 in ?? () from /usr/lib/libphonon.so.4 #13 0x08734130 in ?? () #14 0xb703bff4 in ?? () from /usr/lib/libphonon.so.4 #15 0x08783cb0 in ?? () #16 0xbfb1d228 in ?? () #17 0xbfb1d1e8 in ?? () #18 0xb701caac in Phonon::MediaNodePrivate::deleteBackendObject () from /usr/lib/libphonon.so.4 Backtrace stopped: frame did not save the PC #0 0xffffe402 in __kernel_vsyscall ()
Is the problem still occurs ? (Reassinging to phonon anyway)
Created attachment 22531 [details] debug backtrace infinite knotify crashes on startup still happen on my box (LFS) with svn revision 748093 (built with kdesvn-build-1.5) attached debug backtrace as it is rather long (or should those rather be posted as comments?)
SVN commit 749654 by mkretz: don't create/use symbols with standard yy prefix but rather use Solid as prefix. This is needed to get rid of symbol clashes. Next step: hide those symbols CCBUG: 151623 CCBUG: 149290 M +2 -2 CMakeLists.txt M +187 -197 predicate_lexer.c M +13 -13 predicate_lexer.l M +15 -7 predicate_parser.c M +1 -1 predicate_parser.h M +4 -4 predicate_parser.y WebSVN link: http://websvn.kde.org/?view=rev&revision=749654
All Phonon related issues are cleared up. AFAIK the original issue "After crashing twice in a row, stop triggering knotify and tell the user how he can re-enable it, if the issue is solved." still remains, though. Reassigning back to knotify.
I've repported same problem on this bug: http://bugs.kde.org/show_bug.cgi?id=154011
Every time plasma crashes, knotify4 stays alive. When a new session is launched a new knotify4 daemon is invoked, blocking the use of /dev/snd/pcmC0D0p. This is a side effect of not having a good mixing support in my sound card, but the daemon should definitely try to look for other instances of itself before continuing to load. This problem, pretty similar to the one in this thread, is happening in KDE 4.0.2 with Knotify 4.0.
I got a message like "knotify crashes" after i had started my compiled kde4-svn -build by the helping script "kdesvn-build" at 2008-04-18, 16:27 CEST (= 4:27 p.m. CEST ) The bug-tracking-system gave the output: Anwendung: KNotify (knotify4), Signal SIGSEGV Using host libthread_db library "/lib/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread 0x2aae31e04260 (LWP 1774)] [New Thread 0x41001950 (LWP 1778)] [New Thread 0x40800950 (LWP 1776)] [KCrash handler] #5 QApplication::x11ProcessEvent (this=0x7fff7f0d52c0, event=0x7fff7f0d4e30) at ../../include/QtCore/../../../../qt-copy/src/corelib/tools/qlist.h:89 #6 0x00002aae2d639ee3 in x11EventSourceDispatch (s=0x633600, callback=0, user_data=0x0) at /home/kdeveloper/kdesvn/qt-copy/src/gui/kernel/qguieventdispatcher_glib.cpp:148 #7 0x00002aae31314f92 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #8 0x00002aae31318236 in ?? () from /usr/lib/libglib-2.0.so.0 #9 0x00002aae313186cf in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 #10 0x00002aae2bf82b7e in QEventDispatcherGlib::processEvents (this=0x623600, flags=<value optimized out>) at /home/kdeveloper/kdesvn/qt-copy/src/corelib/kernel/qeventdispatcher_glib.cpp:325 #11 0x00002aae2d639cff in QGuiEventDispatcherGlib::processEvents ( this=0x6b5560, flags=<value optimized out>) at /home/kdeveloper/kdesvn/qt-copy/src/gui/kernel/qguieventdispatcher_glib.cpp:204 #12 0x00002aae2bf5e1a5 in QEventLoop::processEvents ( this=<value optimized out>, flags=@0x7fff7f0d51c0) at /home/kdeveloper/kdesvn/qt-copy/src/corelib/kernel/qeventloop.cpp:149 #13 0x00002aae2bf5e326 in QEventLoop::exec (this=0x7fff7f0d5200, flags=@0x7fff7f0d5210) at /home/kdeveloper/kdesvn/qt-copy/src/corelib/kernel/qeventloop.cpp:196 #14 0x00002aae2bf6030e in QCoreApplication::exec () at /home/kdeveloper/kdesvn/qt-copy/src/corelib/kernel/qcoreapplication.cpp:845 #15 0x0000000000406359 in main (argc=1, argv=0x7fff7f0d5658) at /home/kdeveloper/kdesvn/kdebase/runtime/knotify/main.cpp:68 #0 0x00002aae3013c241 in nanosleep () from /lib/libc.so.6
The the original reporters: I suppose this should be working already from a long time ago. Does anyone else experience this kind of issues with a recent KDE 4.2 /4.3trunk version ? Thanks
I still have this problem with KDE 4.4.4 (opensuse 11.3 packages) It keeps on starting up and everytime it crashes again...
Tom, could you check if your crashes are the same as bug 226721 ? Then we are talking about a different issue here.
If you can provide the information requested in comment #11 or comment #13, please add it.
I've upgraded to opensuse 11.4 a few month ago and I no longer have this problem
Thanks for the update, marking this as fixed, until someone can reproduce.