Summary: | korganizer 3.4 crashes when loading 3.3 calendar files that contain recurring todos | ||
---|---|---|---|
Product: | [Applications] korganizer | Reporter: | Ari Steinberg <ari.steinberg> |
Component: | general | Assignee: | Reinhold Kainhofer <reinhold> |
Status: | RESOLVED FIXED | ||
Severity: | crash | CC: | orion, rdieter, tim |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Debian testing | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
Ari Steinberg
2005-04-13 00:15:08 UTC
This todo causes exactly the same problem for me: BEGIN:VTODO DTSTAMP:20050502T104500Z ORGANIZER:MAILTO:bram_s@hccnet.nl COMMENT:NoStartDate CREATED:20041020T181700Z UID:libkcal-1171727850.887 SEQUENCE:5 LAST-MODIFIED:20041029T105900Z DESCRIPTION:kdelibs\nkdebase\nkdepim\nkoffice SUMMARY:CVS-checkout doen CLASS:PUBLIC PRIORITY:3 CATEGORIES:KDE RRULE:FREQ=WEEKLY;UNTIL=20041029;INTERVAL=1;BYDAY=TU,TH,FR DUE;VALUE=DATE:20041021 DTSTART;VALUE=DATE:29350930228 COMPLETED:20041029T105900Z PERCENT-COMPLETE:100 RECURRENCE-ID:20041028T220000Z END:VTODO Guess there's something wrong with calculating the recurrence. Thanks for the pointer. Rather than reoccuring todos it's the reoccuring todos that have an ending date set. The normal Reoccuring todos loads fine. After I manually removed the reoccuring todos with ending date set, korganizer started up just fine. I am using kde 3.4.1 in gentoo Linux This RRULE on a VTODO in my .ics file also causes korganizer to crash or hang: RRULE :FREQ=DAILY;UNTIL=20050701;INTERVAL=1 Remove the "UNTIL=20050701;" and korganizer opens the file containing the VTODO fine. So yes, it seems it's not recurrence that's the problem, but a recurrence with an ending date. Well, not every instance of a recurring todo with an end date appear to cause the problem. Other recurring todo's with end dates appear to be okay. This is still present in 3.5.2. Tried to track down, but getting lost. Looks like getNextDate() is returning a date of 0, in the inner loop below, so it loops infinitely. bool Todo::recurTodo() { if ( doesRecur() ) { Recurrence *r = recurrence(); QDateTime endDateTime = r->endDateTime(); QDateTime nextDate = r->getNextDateTime( dtDue() ); if ( ( r->duration() == -1 || ( nextDate.isValid() && endDateTime.isValid() && nextDate <= endDateTime ) ) ) { setDtDue( nextDate ); while ( !recursAt( dtDue() ) || dtDue() <= QDateTime::currentDateTime() ) { setDtDue( r->getNextDateTime( dtDue() ) ); } setCompleted( false ); setRevision( revision() + 1 ); return true; } } return false; } SVN commit 599882 by bram: Prevent infinite loops with some cases of recurring todos. BUG:103761 BUG:129474 M +9 -3 todo.cpp --- branches/KDE/3.5/kdepim/libkcal/todo.cpp #599881:599882 @@ -275,11 +275,17 @@ if ( ( r->duration() == -1 || ( nextDate.isValid() && endDateTime.isValid() && nextDate <= endDateTime ) ) ) { - setDtDue( nextDate ); - while ( !recursAt( dtDue() ) || dtDue() <= QDateTime::currentDateTime() ) { - setDtDue( r->getNextDateTime( dtDue() ) ); + + while ( !recursAt( nextDate ) || nextDate <= QDateTime::currentDateTime() ) { + + if ( !nextDate.isValid() || nextDate > endDateTime ) { + return false; + } + + nextDate = r->getNextDateTime( nextDate ); } + setDtDue( nextDate ); setCompleted( false ); setRevision( revision() + 1 ); |