Bug 183631 - kpilotDeamon crashes when a recurring event that ends at midnight is synced
Summary: kpilotDeamon crashes when a recurring event that ends at midnight is synced
Alias: None
Product: kpilot
Classification: Unclassified
Component: General (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR crash (vote)
Target Milestone: ---
Assignee: groot
Depends on:
Reported: 2009-02-07 23:53 UTC by Douglas Harms
Modified: 2009-03-25 13:09 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:

Debug information from kpilotDaemon (334.23 KB, application/gzip)
2009-02-21 19:13 UTC, Marcus Gama
Kcrash debug information (4.40 KB, application/octet-stream)
2009-02-21 19:13 UTC, Marcus Gama

Note You need to log in before you can comment on or make changes to this bug.
Description Douglas Harms 2009-02-07 23:53:03 UTC
Version:            (using Devel)
Compiler:          gcc 4.3.2 
OS:                Linux
Installed from:    Compiled sources

When a recurring event that ends at midnight is created in korganizer and then synced, kpilotDaemon crashes.  (Strangely, it seems to handle non-recurring events that end at midnight OK.)

I'm working on narrowing down the problem (a QASSERT is violated) and will hopefully have a patch/solution sometime soon.
Comment 1 Douglas Harms 2009-02-08 23:57:16 UTC
I've been looking into this problem and, though I haven't solved it yet, I wanted to post a quick update.

When a new calendar hh record is created CalendarConduit::createHHRecord is called.  After making a copy of the pc record createHHRecord verifies that the copy was correct by calling Q_ASSERT(equal(pcRec,hhRec)).  When the pcrec contains a recurring event that ends at midnight, equal returns false which causes kpilotDaemon to crash (i.e., that's what Q_ASSERT does).

So, why does equal return false in this situation?  The problem is the TEST of dtEnd (line 159::calendarconduit.cc) fails.  After quite a bit of debugging I found out that when the end time is midnight the pc (correctly) specifies the end time as midnight of the next day.  (e.g., if the event starts at 10:00pm on February 8 and lasts 2 hours, the end time is recorded as 00:00 on February 9.)  However, the palm doesn't allow events to span days so when the record is packed for the palm the end date is changed to be the same as the start (i.e., the end time is 00:00 on February 8, not the 9th.)  Thus, when the pc record is compared with the newly created hh record the ending times are different (the pc record ends on a different day than the hh record), so the records are not equal.

Why do non-recurring records that end at midnight not cause this problem?  If I understand the code correctly, a non-recurring event that ends at midnight is considered a multi-day event, and when compared for equality multi-day events do not compare the ending times.  Unfortunately, for an event to be considered a multi-day event it cannot have a recurrence (see the definition of isMultiDay in pilotDateEntry.h).

I'm working on ideas for addressing this problem and will hopefully propose something in the coming days.  I've also noticed that multi day events are kinda weird, and I'm wondering if maybe I should be trying to find a way to address some of these weirdnesses too.  (For example, an event created on the pc that starts at 10:00pm on Feb 8 and ends at 9:00am on February 9 appears on the palm as a repeating event on the 8th and 9th that starts at 10:00pm each day and ends at 9:00am each day.  Pretty bizarre, though I understand the issues.)

Anyway, just wanted to update this bug in case anyone is interested.

Comment 2 Bertjan Broeksema 2009-02-20 23:07:07 UTC
SVN commit 929209 by bbroeksema:

This fixes a crash when an event on the pc ends at midnight. In this case a
record on the handheld is created which also ends at 00:00 but on the same
date as it starts in stead of the next day. 

I don't close the bug yet because the behavior of pc events running from
day 1 10:00pm to day 2 9:00 am is not fixed by this commit. (Although I wonder
if we will be able to actually fix this.)

CCBUG: 183631

 M  +13 -1     calendarconduit.cc  

WebSVN link: http://websvn.kde.org/?view=rev&revision=929209
Comment 3 Jason 'vanRijn' Kasper 2009-02-21 17:50:15 UTC
Adding Marcus who reported the same problem on bug #182932.
Comment 4 Marcus Gama 2009-02-21 19:10:33 UTC
I was assigned to this bug recently (see post above).  Jason asked to me to report on this bug my problem. He told me to compile from svn and test again if KPilot is working (a patched was commited yesterday that fix this bug - I suppose). I did (right now) and tested again. Unfortunately, the crash persist. I will attached two files (debug info from KPilot and debug info from crash). Details about my KPilot:

Version: KPilot 5.2.1-pre1 (KDE 4.2.1)
Version: pilot-link 0.12.3
Version: KDE 4.2.00 (KDE 4.2.0)
Version: Qt 4.4.3

My calendar is too big (about 2000 registers), The problem happened with the calendar conduit. Actually, I don't know if I have a recurring event that ends at midnight, but anyway, every time that I try to sync my calendar, kpilotDaemon crashes. I'm using KUbuntu 8.10 with KDE 4.2 packages. KPilot was built manually by myself from SVN (as I said before).

I'm available for any kind of testing to try to solve this bug. I really would like to migrate to the new KDE 4.2, but without sync my Palm, it's not possible. KPilot works fine for me using KDE 3.5.9. Using Ubuntu, I can sync with no problems using GPilot. But crashes with KDE 4.2.
Comment 5 Marcus Gama 2009-02-21 19:13:11 UTC
Created attachment 31520 [details]
Debug information from kpilotDaemon

See post above
Comment 6 Marcus Gama 2009-02-21 19:13:52 UTC
Created attachment 31521 [details]
Kcrash debug information

See post above
Comment 7 Bertjan Broeksema 2009-02-23 09:40:07 UTC
Hi Marcus,

Last lines of your log looks like this:

             > equal 
!    "DtRepeatEnd" , a: [ QDateTime("qua fev 2 00:00:00 2005") ] not equal to b: [ QDateTime("qui fev 3 00:00:00 2005") ]. 

I'm quite sure that I fixed this in r929209. Could you make sure that you did build and install this actual revision and try again?
Comment 8 Marcus Gama 2009-02-23 13:23:49 UTC

Unfortunately, at least for me this bug is not solved. I checked again and I have in my computer r929676 for kpilot root folder and r929209 for conduits folder (some few changes in other folders). From my last built, it was changed the version of KPilot: from  "KPilot 5.2.1-pre1 (KDE 4.2.1)" to  "KPilot 5.2.1 (KDE 4.2.1)" (no pre1). I did a hard reset at my Palm, but I have my saved ical file at Kontact. When I try to sync (Palm Agenda empty and Kontact Agenda full), the same problem: KPilot crash. As before, I pasted below the last lines of my kpilotDaemon.debug:

!    "DtEventEnd" , a: [ QDateTime("dom out 19 00:00:00 2008") ] not equal to b: [ QDateTime("sáb out 18 00:00:00 2008") ]. 
ASSERT: "equal( pcRec, hhRec )" in file /home/marcus/KPilot/SVN/work/kpilot-stable/conduits/calendar/calendarconduit.cc, line 295
KCrash: Application 'kpilotDaemon' crashing...

Note about the date: dom out = sunday october (my language is portuguese)
                     sáb out = saturday october

I really would like to see kpilot working with KDE 4.2. This is my last dependency to migrate definitely my system to KDE 4.2. And I really appreciate this great software. My Palm worked OK with KDE 3.5.9 and with Gnome (using GPilot).


Marcus Gama
Comment 9 Marcus Gama 2009-02-23 13:42:03 UTC
Bellow, I included the last lines of my kpilotDaemon.debug (with more information).

               > _copy 
                 > dateEntry 
                 > item 
                  Summary:  "VEE" 
                 > setStartEndTimes 
                    event start:  "dom out 19 00:00:00 2008" 
                    event end :  "dom out 19 00:00:00 2008" 
                 > setAlarms 
                 > setRecurrence 
                    Start date:  "dom out 19 00:00:00 2008" , end date:  "dom out 19 00:00:00 2008" 
                    Setting end date:  "sex out 31 2008" 
                    Event:  "VEE" , duration:  0 , endDate:  "sex out 31 2008" , ValidEndDate:  true , NullEndDate:  false 
                 > setExceptions 
                 > setDescriptionP 
                 > setNoteP 
                 > setDateEntry 
             > equal 
               > item 
               > dateEntry 
               > category 
               > category 
               > category 
               > dtStart 
               > dtEnd 
!    "DtEventEnd" , a: [ QDateTime("dom out 19 00:00:00 2008") ] not equal to b: [ QDateTime("sáb out 18 00:00:00 2008") ]. 
ASSERT: "equal( pcRec, hhRec )" in file /home/marcus/KPilot/SVN/work/kpilot-stable/conduits/calendar/calendarconduit.cc, line 295
KCrash: Application 'kpilotDaemon' crashing...

The event above is an event with no time associated (Start date:  "dom out 19 00:00:00 2008" , end date:  "dom out 19 00:00:00 2008") and with recurrence (Setting end date:  "sex out 31 2008"). Translating the dates for english:

Start date:  "sun oct 19 00:00:00 2008" , end date:  "sun oct 19 00:00:00 2008"
Setting end date:  "fri oct 31 2008"

Maybe this information can help.
Comment 10 Douglas Harms 2009-02-25 21:46:07 UTC
FYI, I've confirmed Marcus' behavior and have a proposed patch posted to http://reviewboard.kde.org/r/186/

It seems that events inserted on the PC that do not have a time associated with them are defined with midnight for both start and end times.  When the hh record created from this pc record is packed, the end date is apparently NOT modified (as it is for an event that ends at midnight but starts at a time other than midnight).  Thus, when we check the endtime we should not subtract one from the date for these records.
Comment 11 Jason 'vanRijn' Kasper 2009-02-25 22:10:29 UTC
Gah. This is bad. We need to get this fixed for 4.2.1.
Comment 12 Douglas Harms 2009-02-26 09:18:06 UTC
SVN commit 931909 by dharms:

Fixes a bug where recurring events that had no time associated with them
weren't synced correctly.

BUG: 183631

 M  +7 -5      calendarconduit.cc  

WebSVN link: http://websvn.kde.org/?view=rev&revision=931909