Version: (using KDE 4.3.0) OS: Linux Installed from: Debian testing/unstable Packages On my machine, kalarm crashes on every login. I already had this behaviour with KDE 4.2, and it persists after update to 4.3. AFAICT, this looks different from other startup crashes reported. -- Backtrace: Application: KAlarm (kalarm), signal: Segmentation fault [KCrash Handler] #6 MessageWin::showEvent (this=0x89365a8, se=0xbf80934c) at /usr/include/qt4/QtGui/qwidget.h:973 #7 0xb692e56d in QWidget::event (this=0x89365a8, event=0xbf80934c) at kernel/qwidget.cpp:7748 #8 0xb6cf23d7 in QMainWindow::event (this=0x89365a8, event=0xbf80934c) at widgets/qmainwindow.cpp:1399 #9 0xb78ee5f7 in KMainWindow::event (this=0x89365a8, ev=0xbf80934c) at ../../kdeui/widgets/kmainwindow.cpp:1094 #10 0xb79335bc in KXmlGuiWindow::event (this=0x89365a8, ev=0xbf80934c) at ../../kdeui/xmlgui/kxmlguiwindow.cpp:131 #11 0xb68d87d4 in QApplicationPrivate::notify_helper (this=0x873feb8, receiver=0x89365a8, e=0xbf80934c) at kernel/qapplication.cpp:4056 #12 0xb68e0a12 in QApplication::notify (this=0x87327a8, receiver=0x89365a8, e=0xbf80934c) at kernel/qapplication.cpp:4021 #13 0xb780c00d in KApplication::notify (this=0x87327a8, receiver=0x89365a8, event=0xbf80934c) at ../../kdeui/kernel/kapplication.cpp:302 #14 0xb729896b in QCoreApplication::notifyInternal (this=0x87327a8, receiver=0x89365a8, event=0xbf80934c) at kernel/qcoreapplication.cpp:610 #15 0xb6933c03 in QWidgetPrivate::show_helper (this=0x89367e0) at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:213 #16 0xb69341eb in QWidget::setVisible (this=0x89365a8, visible=true) at kernel/qwidget.cpp:6975 #17 0x080f1943 in MessageWin::show (this=0x89365a8) at /usr/include/qt4/QtGui/qwidget.h:473 #18 0x080e3ddb in KAlarmApp::restoreSession (this=0x87327a8) at ../../kalarm/kalarmapp.cpp:232 #19 0x08097262 in main (argc=3, argv=0xbf809894) at ../../kalarm/main.cpp:125
Do you run KAlarm manually after it crashes, and if so, does it run successfully? Could you please attach these files: ~/.kde/share/apps/kalarm/displaying.ics ~/.kde/share/config/kalarmrc
Created attachment 36179 [details] displaying.ics
Created attachment 36180 [details] kalarmrc
Sorry for missing this information when reporting: Although kalarm reports a crash, it does start up after some time.
Thank you. Unfortunately I can't reproduce the crash using the files. 1) When you say that it does start up after some time, do you mean that it starts up without you needing to do anything, or do you have to start it manually? 2) Do you have the kdepim-dbg package installed?
Yes, after the crash report kalarm starts up by itself. (Strange enough... Might it be that KDE starts it twice?) I have installed the kdepim-dbg package. KDE considered the call stack to be useful. (...but it wasn't able to send it itself for some unsepcified error.)
The call stack does look reasonable, but it doesn't give enough information to see why it's going wrong. Could you please try enabling debug output for KAlarm, and attaching the output. Run 'kdebugdialog --fullmode' and select '5950 kalarm'. Set Information and Warning output to 'File' and enter a filename to contain the debug output. Then, after KAlarm has crashed, attach the file to this bug report. After that, you may wish to set KAlarm's debug output back to 'Shell' again to avoid having a forever growing log file.
Created attachment 36232 [details] log when the crash report is open
Created attachment 36233 [details] log after closing crash report, when kalarm has started
What is happening is that when you log on, the KDE session restoration tells KAlarm to restore its state from when you logged off. It is crashing during this process - it looks as if the alarm message window which is being restored is not initialised properly. Since there will not always be a saved state from last time, KAlarm is also autostarted on login. This occurs after session restoration, and this is what starts KAlarm after the crash. There should be at least one file ~/.kde/share/config/session/kalarm_*. Can you please attach this/these.
Created attachment 36245 [details] ~/.kde/share/config/session/kalarm_10d0d36e61000125054743700000040460017_1250549215_950722
Created attachment 36246 [details] ~/.kde/share/config/session/kalarm_10d0d36e61000111695411300000069660008_1119364459_984505
Created attachment 36247 [details] ~/.kde/share/config/session/kalarm_10d0d36e61000111073354500000033350007_1110926797_286356
If alarms are currently on display when you log off, KAlarm stores their details so as to be able to restore the alarm windows when you log on again. At some time in the past, two such alarms were stored with an invalid alarm type, and the crash occurs because KAlarm doesn't handle this properly. I now have a fix for the crash, but there is still the problem that the invalid alarm types shouldn't have been saved in the first place. Even with the crash fixed, KAlarm can't restore alarm windows which have been saved wrongly. To help find out why they were saved wrongly, do you remember how the alarms were created? Do you always use the alarm edit dialog to create alarms, or do you sometimes use command line options, or D-Bus calls from another program? The alarms in question are those in displaying.ics which you attached, with the UID entries ending in 2031300610.155 and 1017867061.963.
Both alarms have been set using the kalarm dialog. 1017867061.963 might be from May, 2031300610.155 probably was set on June 6th (or maybe some days later). I had a look in my package installation log. I upgraded from Debian kalarm package 3.5.9-5 to 4.2.2-1 on 2009-04-07 and to 4:4.2.4-1 on 2009-06-07. So probably both alarms were set with version 4.2.2-1.
I've finally found where the invalid alarm status is coming from. This has now been fixed for KDE 4.3.1 (SVN commits 1013042, 1013043, 1013437, 1013438). Thank you for all your help in tracking this down.
Thanks for you excellent bug handling!