Bug 203957 - kalarm crashes on every startup (call stack included)
Summary: kalarm crashes on every startup (call stack included)
Status: CLOSED FIXED
Alias: None
Product: kalarm
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Debian testing Linux
: NOR crash
Target Milestone: ---
Assignee: David Jarvie
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-08-15 16:03 UTC by eikes
Modified: 2010-09-02 12:36 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
displaying.ics (3.35 KB, text/calendar)
2009-08-15 20:28 UTC, eikes
Details
kalarmrc (1.65 KB, application/octet-stream)
2009-08-15 20:28 UTC, eikes
Details
log when the crash report is open (1.60 KB, application/octet-stream)
2009-08-17 20:38 UTC, eikes
Details
log after closing crash report, when kalarm has started (3.85 KB, application/octet-stream)
2009-08-17 20:39 UTC, eikes
Details
~/.kde/share/config/session/kalarm_10d0d36e61000125054743700000040460017_1250549215_950722 (2.60 KB, application/octet-stream)
2009-08-18 09:47 UTC, eikes
Details
~/.kde/share/config/session/kalarm_10d0d36e61000111695411300000069660008_1119364459_984505 (575 bytes, application/octet-stream)
2009-08-18 09:47 UTC, eikes
Details
~/.kde/share/config/session/kalarm_10d0d36e61000111073354500000033350007_1110926797_286356 (272 bytes, application/octet-stream)
2009-08-18 09:48 UTC, eikes
Details

Note You need to log in before you can comment on or make changes to this bug.
Description eikes 2009-08-15 16:03:28 UTC
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
Comment 1 David Jarvie 2009-08-15 20:13:16 UTC
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
Comment 2 eikes 2009-08-15 20:28:00 UTC
Created attachment 36179 [details]
displaying.ics
Comment 3 eikes 2009-08-15 20:28:46 UTC
Created attachment 36180 [details]
kalarmrc
Comment 4 eikes 2009-08-15 20:29:55 UTC
Sorry for missing this information when reporting:
Although kalarm reports a crash, it does start up after some time.
Comment 5 David Jarvie 2009-08-16 00:48:20 UTC
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?
Comment 6 eikes 2009-08-16 00:57:52 UTC
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.)
Comment 7 David Jarvie 2009-08-16 19:28:44 UTC
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.
Comment 8 eikes 2009-08-17 20:38:27 UTC
Created attachment 36232 [details]
log when the crash report is open
Comment 9 eikes 2009-08-17 20:39:26 UTC
Created attachment 36233 [details]
log after closing crash report, when kalarm has started
Comment 10 David Jarvie 2009-08-18 01:26:52 UTC
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.
Comment 11 eikes 2009-08-18 09:47:03 UTC
Created attachment 36245 [details]
~/.kde/share/config/session/kalarm_10d0d36e61000125054743700000040460017_1250549215_950722
Comment 12 eikes 2009-08-18 09:47:33 UTC
Created attachment 36246 [details]
~/.kde/share/config/session/kalarm_10d0d36e61000111695411300000069660008_1119364459_984505
Comment 13 eikes 2009-08-18 09:48:01 UTC
Created attachment 36247 [details]
~/.kde/share/config/session/kalarm_10d0d36e61000111073354500000033350007_1110926797_286356
Comment 14 David Jarvie 2009-08-18 14:53:42 UTC
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.
Comment 15 eikes 2009-08-19 19:34:47 UTC
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.
Comment 16 David Jarvie 2009-08-19 23:18:28 UTC
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.
Comment 17 eikes 2009-08-19 23:23:20 UTC
Thanks for you excellent bug handling!