Version: (using KDE KDE 3.4.0) Installed from: Debian testing/unstable Packages OS: Linux I am using the new Debian 3.4 packages from Alioth, which are for KDE 3.4. When I upgraded, I found that korganizer would not run...cpu utilization jumps to 100% and the program does not start up (it hangs). Similarly, kontact would also sometimes hang, I think when it attempted to start korganizer. I moved away my old .kde/share/apps/korganizer/ directory and found it started normally. I then tried loading the old .ics file from that directory and found it crashed when trying to import/load. Finally, I manually editted the .ics file and tried removing events/todos from the file until it started to work again. I was eventually able to figure out that this TODO is the one that caused it to crash: BEGIN:VTODO DTSTAMP:20050410T204441Z ORGANIZER:MAILTO:ari.steinberg@stanford.edu COMMENT:NoStartDate CREATED:20041003T232125Z UID:KOrganizer-476329157.708 SEQUENCE:17 LAST-MODIFIED:20041202T024301Z SUMMARY:CS205 Problem Set CLASS:PUBLIC PRIORITY:3 RRULE:FREQ=WEEKLY;UNTIL=20041205;INTERVAL=1;BYDAY=WE DUE:20041020T211500Z DTSTART:20041006T211500Z COMPLETED:20041202T024301Z PERCENT-COMPLETE:100 RECURRENCE-ID:20041201T221500Z END:VTODO I think this should be treated with very high priority since it effectively prevented me from using Kontact/KOrganizer after upgrading to KDE 3.4, and nearly caused me to resort to deleting my entire organizer files. Let me know if you need any additional information.
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 );