Version: 2.07 (using KDE 4.2.2) OS: Linux Installed from: Debian stable Packages In either the countdown or the set time, if the time of the alarm occurs while the computer is off - and the alarm is set to turn off if missed, then KAlarm crashes the system when the computer is turned back on. (If the alarm is not set to skip if missed, then all alarms that occurred while the computer was off will be activated at bootup - this is annoying since these alarms are no longer relevant). The same error was observed in Ubuntu 8.10 and 9.04. I'm using alltray to automatically put KAlarm in my tray at startup. The sessions command is "alltray kalarm".
The bug report provided is: This backtrace appears to be of no use. This is probably because your packages are built in a way which prevents creation of proper backtraces, or the stack frame was seriously corrupted in the crash. (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) . . . skip numerous lines . . . (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread 0xb52fe6c0 (LWP 5913)] (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) . . . skip numerous lines . . . (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) 0xb8037430 in __kernel_vsyscall () [Current thread is 0 (process 5913)] Thread 1 (Thread 0xb52fe6c0 (LWP 5913)): #0 0xb8037430 in __kernel_vsyscall () #1 0xb6649733 in waitpid () from /lib/tls/i686/cmov/libc.so.6 #2 0xb7a3deef in ?? () from /usr/lib/libkdeui.so.5 #3 0xb7a3ee83 in KCrash::defaultCrashHandler () from /usr/lib/libkdeui.so.5 #4 <signal handler called> #5 0xb73f844c in QString::QString () from /usr/lib/libQtCore.so.4 #6 0xb744ef04 in ?? () from /usr/lib/libQtCore.so.4 #7 0xb744a8fb in QTextStream::operator<< () from /usr/lib/libQtCore.so.4 #8 0x0813af35 in ?? () #9 0x080dc376 in _start () #0 0xb8037430 in __kernel_vsyscall ()
Could you please try installing kdepim-dbg package to see if it will generate a usable stack trace when it crashes - the one supplied doesn't give any clue as to what's happening. You should note that you don't need to use alltray to put KAlarm in the system tray at startup - KAlarm does that itself if it's configured to show in the system tray.
I installed kdepim-dbg and recreated the error. It's still saying "Sorry - The KDE Crash Handler Unable to create a valid backtrace. This bactrace appears to be of no use. This is probably because your backages are built in a way which prevents creation of proper backtraces, or the stack frame was seriously corrupted in the crash." However, this time it is providing more information to the signal 11 (SIGSEGV): This backtrace appears to be of no use. This is probably because your packages are built in a way which prevents creation of proper backtraces, or the stack frame was seriously corrupted in the crash. [Thread debugging using libthread_db enabled] [New Thread 0xb52286c0 (LWP 6083)] 0xb7f61430 in __kernel_vsyscall () [Current thread is 0 (process 6083)] Thread 1 (Thread 0xb52286c0 (LWP 6083)): #0 0xb7f61430 in __kernel_vsyscall () #1 0xb6573733 in waitpid () from /lib/tls/i686/cmov/libc.so.6 #2 0xb7967eef in KCrash::startDirectly (argv=0xbf95f8f4) at /build/buildd/kde4libs-4.1.4/kdeui/util/kcrash.cpp:436 #3 0xb7968e83 in KCrash::defaultCrashHandler (sig=11) at /build/buildd/kde4libs-4.1.4/kdeui/util/kcrash.cpp:340 #4 <signal handler called> #5 0xb654fbb6 in memcpy () from /lib/tls/i686/cmov/libc.so.6 #6 0xb66321f0 in ?? () from /lib/tls/i686/cmov/libc.so.6 #7 0xb7378e72 in ?? () from /usr/lib/libQtCore.so.4 #8 0xb73748fb in QTextStream::operator<< () from /usr/lib/libQtCore.so.4 #9 0x0813af35 in KAlarm::updateEvent (event=@0x933cab8, msgParent=0x0, archiveOnDelete=true) at /usr/include/qt4/QtCore/qdebug.h:103 #10 0x080dc376 in KAlarmApp::handleEvent (this=0x92828e8, eventID=@0x937197c, function=KAlarmApp::EVENT_HANDLE) at /build/buildd/kdepim-4.1.4/kalarm/kalarmapp.cpp:1481 #11 0x080dd5b8 in KAlarmApp::processQueue (this=0x92828e8) at /build/buildd/kdepim-4.1.4/kalarm/kalarmapp.cpp:996 #12 0x080e1f9b in KAlarmApp::qt_metacall (this=0x92828e8, _c=QMetaObject::InvokeMetaMethod, _id=3, _a=0xbf960408) at /build/buildd/kdepim-4.1.4/obj-i486-linux-gnu/kalarm/kalarmapp.moc:94 #13 0xb73e5a60 in QMetaObject::activate () from /usr/lib/libQtCore.so.4 #14 0xb73e67e2 in QMetaObject::activate () from /usr/lib/libQtCore.so.4 #15 0xb73ebdb7 in ?? () from /usr/lib/libQtCore.so.4 #16 0xb73ebedc in ?? () from /usr/lib/libQtCore.so.4 #17 0xb73e053f in QObject::event () from /usr/lib/libQtCore.so.4 #18 0xb6ac18ec in QApplicationPrivate::notify_helper () from /usr/lib/libQtGui.so.4 #19 0xb6ac972e in QApplication::notify () from /usr/lib/libQtGui.so.4 #20 0xb78fad1d in KApplication::notify (this=0x92828e8, receiver=0x9376210, event=0xbf96089c) at /build/buildd/kde4libs-4.1.4/kdeui/kernel/kapplication.cpp:311 #21 0xb73d0e61 in QCoreApplication::notifyInternal () from /usr/lib/libQtCore.so.4 #22 0xb73fed81 in ?? () from /usr/lib/libQtCore.so.4 #23 0xb73fb520 in ?? () from /usr/lib/libQtCore.so.4 #24 0xb587b718 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #25 0xb587edc3 in ?? () from /usr/lib/libglib-2.0.so.0 #26 0xb587ef81 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 #27 0xb73fb478 in QEventDispatcherGlib::processEvents () from /usr/lib/libQtCore.so.4 #28 0xb6b5bea5 in ?? () from /usr/lib/libQtGui.so.4 #29 0xb73cf52a in QEventLoop::processEvents () from /usr/lib/libQtCore.so.4 #30 0xb73cf6ea in QEventLoop::exec () from /usr/lib/libQtCore.so.4 #31 0xb73d1da5 in QCoreApplication::exec () from /usr/lib/libQtCore.so.4 #32 0xb6ac1767 in QApplication::exec () from /usr/lib/libQtGui.so.4 #33 0x0809464e in main (argc=1, argv=0xbf960f24) at /build/buildd/kdepim-4.1.4/kalarm/main.cpp:123 #0 0xb7f61430 in __kernel_vsyscall () Thank you.
This has now been fixed, just in time for KDE 4.2.3 (SVN commits 961247, 961249).
Does this mean that the next version of kalarm has been fixed for gnome, or does it have to be run in KDE?
It should work under Gnome as well - there's no change in that respect.