Bug 101696 - korganizer crash at startup for a particular std.ics file
Summary: korganizer crash at startup for a particular std.ics file
Status: RESOLVED FIXED
Alias: None
Product: korganizer
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Debian testing Linux
: NOR crash (vote)
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-03-17 15:27 UTC by berti
Modified: 2006-12-16 11:21 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments
the bogus std.ics file (723 bytes, application/octet-stream)
2005-03-17 15:29 UTC, berti
Details

Note You need to log in before you can comment on or make changes to this bug.
Description berti 2005-03-17 15:27:44 UTC
Version:            (using KDE KDE 3.3.2)
Installed from:    Debian testing/unstable Packages
OS:                Linux

If I try to launch korganizer, I get the following error :

berti@venus:~/code/kynaptic-kde/src$ korganizer
ERROR: Communication problem with korganizer, it probably crashed.

After some research, it appears that if I remove my ~/.kde/share/apps/korganizer/std.ics file, korganizer is working.

I've succeed to reduc my std.ics file to two entries. If these entries are there, korganizer crash. If only one of the two is removed (any of the two), korganizer is working.

In attachment, I put the std.ics file.
Comment 1 berti 2005-03-17 15:29:26 UTC
Created attachment 10163 [details]
the bogus std.ics file
Comment 2 Bram Schoenmakers 2005-09-01 23:43:52 UTC
Still crashes in today's 3.5 branch.
Comment 3 Reinhold Kainhofer 2006-11-02 18:51:06 UTC
Reassigning all KOrganizer bug reports and wishes to the newly created 
korganizer-devel mailing list.
Comment 4 Martin Koller 2006-12-16 11:21:52 UTC
SVN commit 614095 by mkoller:

BUG: 101696
Break recursive relation to avoid endless loop


 M  +14 -1     kotodoview.cpp  


--- branches/KDE/3.5/kdepim/korganizer/kotodoview.cpp #614094:614095
@@ -590,6 +590,9 @@
     // Use dynamic_cast, because in the future the related item might also be an event
     Todo *relatedTodo = dynamic_cast<Todo *>(incidence);
 
+    // just make sure we know we have this item already to avoid endless recursion (Bug 101696)
+    mTodoMap.insert(todo,0);
+
 //    kdDebug(5850) << "  has Related" << endl;
     QMap<Todo *,KOTodoViewItem *>::ConstIterator itemIterator;
     itemIterator = mTodoMap.find(relatedTodo);
@@ -599,7 +602,17 @@
     }
     // isn't this pretty stupid? We give one Todo  to the KOTodoViewItem
     // and one into the map. Sure finding is more easy but why? -zecke
-    KOTodoViewItem *todoItem = new KOTodoViewItem(*itemIterator,todo,this);
+    KOTodoViewItem *todoItem;
+
+    // in case we found a related parent, which has no KOTodoViewItem yet, this must
+    // be the case where 2 items refer to each other, therefore simply create item as root item
+    if ( *itemIterator == 0 ) {
+      todo->setRelatedTo(0);  // break the recursion, else we will have troubles later
+      todoItem = new KOTodoViewItem(mTodoListView,todo,this);
+    }
+    else
+      todoItem = new KOTodoViewItem(*itemIterator,todo,this);
+
     return mTodoMap.insert(todo,todoItem);
   } else {
 //    kdDebug(5850) << "  no Related" << endl;