Version: 3.5.3 (using KDE KDE 3.5.4) Installed from: Fedora RPMs Compiler: gcc version 4.1.1 20060525 (Red Hat 4.1.1-1) fairly stock x86_64 Fedora Core 5 system OS: Linux This is on a 64bit machine, running kde with 64 bit packages (FC5). Trying to use the iCalendar client interface in webcalendar causes KOrganizer to start consuming huge amounts of memory (allowed it to run for 10 minutes or so once, was using over 1GB of mem, machine had to be rebooted as swap storm made system unresponsive). I grabbed the file it was trying to import and pared it down to a minimal entry that could replicate the problem. The following iCalendar file causes my KOrganizer to display the GUI with the skeleton of a month view, then sit there unresponsive, allocating memory and consuming 100% CPU time, seemingly indefinitely. KOrganizer can only seem to be killed by a SIGKILL, standard SIGTERM has no visible effect. Running strace on korganizer during this shows a continuous stream of brk calls. The problem appears to be the DTSTART part with "VALUE=DATETIME" in it. If I comment[1] out the original DTSTART and uncomment the other one with a UTC timestamp everything works fine, and the event appears in the calendar. Note that the commented entry is one I added myself for testing, and is not part of the original file from webcalendar. I am using a CVS version of webcalendar, so it is possible that the source data is incorrect (it looks ok to me, but what would I know!) - however even if the input is garbage KOrganizer should handle the situation better, rather than grind the system to a halt (well, my system, anyway). [1]: I don't know if prepending a hash to a line is actually a "comment" in iCalendar speak, but it had the desired result. ---------snip------------- BEGIN:VCALENDAR X-WR-CALNAME;VALUE=TEXT:Ashley Gittins PRODID:-//WebCalendar-v1.1.1 VERSION:2.0 METHOD:PUBLISH BEGIN:VEVENT UID:HTTPS:-my-server-address-here-user-0000000058 SUMMARY:Test appointment DESCRIPTION:Test appointment CLASS:PUBLIC STATUS:CONFIRMED DTSTART;VALUE=DATETIME:20060621T000000 #DTSTART:20060621T000000Z DTSTAMP:20060828T151907Z END:VEVENT END:VCALENDAR ---------/snip------------
Created attachment 17539 [details] Test iCalendar File showing problem Sample test case as an attachment. Warning: set mimetype to text/calendar so this could hang up your browser if you let korganizer open it directly.
Comment on attachment 17539 [details] Test iCalendar File showing problem This test file is broken - I had left the problem-causing line commented. See next attachment.
Created attachment 17642 [details] Test case to trigger memory thrashing in KOrganizer Test case - open this file in KOrganizer, and select "month view". KOrganizer starts using up memory. Should instead show single event entry on Jun 21 2006.
We are 3 days away from this bugreport being a month old, and nobody has been able to confirm if the problem exists outside of my own system? If there is more info I need to provide in order for this bug to be further investigated please just let me know - without any feedback I can't tell if the bug is unreproducible or if more info is required. I have just tried replicating the bug on a 32bit system, and the result is the same - korganizer uses up all available memory, starts swapping madly and effectively locks up the entire system, so it's probably safe to say this bug is not 64-bit specific, nor specific to my desktop machine (it may yet be specific to me :-)). Note that an important step for replicating the bug is being in or switching to "month view" - it seems that not all views display the same behaviour. The 32bit system I tested on was a Fedora Core 5 system, kde from fedora rpms, using kdepim-3.5.3-0.2.fc5.i386, KDE version 3.5.3-0.4.fc5. Given that this bug causes a system to become so wedged that after a few minutes the only solution is to UNPLUG THE POWER I hope that someone could at least try out the sample file given and let me know if the problem is specific to my (two) systems, or if it is a general problem with KOrganizer.
Yes, I can confirm the bug happens in month view. Agenda view seems to handle the event ok. I'll look into a fix for KDE 3.5.5. but I need to hurry as the cutoff for KDE 3.5.5 changes is fast approaching.
Here's a backtrace obtained with "kill -SEGV <pid-of-korg>", but it was a pain to get: #12 0x29ea7b6c in sigaction () from /usr/lib/libpthread.so.2 #13 0x2818ad53 in QMapPrivate<QDate, MonthViewCell*>::find (this=0x8244fc0, k=@0xbfbfdc80) at qmap.h:503 #14 0x2818a995 in QMap<QDate, MonthViewCell*>::operator[] (this=0x82450a4, k=@0xbfbfdc80) at qmap.h:800 #15 0x28189764 in KOMonthView::changeIncidenceDisplayAdded (this=0x8245000, incidence=0x8387988, v=@0xbfbfdd10) at /home/phil/kdesrc/kdepim/korganizer/komonthview.cpp:973 #16 0x28189a27 in KOMonthView::updateView (this=0x8245000) at /home/phil/kdesrc/kdepim/korganizer/komonthview.cpp:1011 #17 0x281893e7 in KOMonthView::showDates (this=0x8245000, start=@0x81addd0) at /home/phil/kdesrc/kdepim/korganizer/komonthview.cpp:903 #18 0x281a06e0 in KOViewManager::updateView (this=0x815c3f8, start=@0x81addd0, end=@0x81ab298) at /home/phil/kdesrc/kdepim/korganizer/koviewmanager.cpp:155 #19 0x28193eae in CalendarView::updateView (this=0x815bf68, start=@0x81addd0, end=@0x81ab298) at /home/phil/kdesrc/kdepim/korganizer/calendarview.cpp:810 #20 0x28193f22 in CalendarView::updateView (this=0x815bf68) at /home/phil/kdesrc/kdepim/korganizer/calendarview.cpp:819 #21 0x281922dd in CalendarView::openCalendar (this=0x815bf68, filename=@0x8243738, merge=false) at /home/phil/kdesrc/kdepim/korganizer/calendarview.cpp:426 #22 0x28218675 in ActionManager::openURL (this=0x82436b8, url=@0xbfbfe060, merge=false) at /home/phil/kdesrc/kdepim/korganizer/actionmanager.cpp:847 #23 0x080518a5 in KOrganizer::openURL (this=0x8155c38, url=@0xbfbfe060, merge=false) at /home/phil/kdesrc/kdepim/korganizer/korganizer.cpp:251
Wow! Thanks Philip. That really gave me the hint I needed. I'm testing a fix now and should have it committed in a little while.
SVN commit 588663 by winterz: Evil, memory eating bug killed. I hope. Thanks to Philip for providing the backtrace which led me to the fix. BUGS: 133165 M +7 -4 komonthview.cpp --- branches/KDE/3.5/kdepim/korganizer/komonthview.cpp #588662:588663 @@ -980,10 +980,13 @@ } } else { // addSecs(-1) is added to handle 0:00 cases (because it's non-inclusive according to rfc) - QDate endDate = gdv.endDate().addSecs( floats ? 0 : -1).date(); - for ( QDate date = gdv.startDate().date(); date <= endDate; date = date.addDays( 1 ) ) { - MonthViewCell *mvc = mDateToCell[ date ]; - if ( mvc ) mvc->addIncidence( incidence, v ); + if ( gdv.endDate().isValid() ) { + QDate endDate = gdv.endDate().addSecs( floats ? 0 : -1).date(); + for ( QDate date = gdv.startDate().date(); + date <= endDate; date = date.addDays( 1 ) ) { + MonthViewCell *mvc = mDateToCell[ date ]; + if ( mvc ) mvc->addIncidence( incidence, v ); + } } } }
Wow guys, fantastic work, both! I don't know if I'll be able to do a checkout and build before the next release, but I will certainly be jumping onto 3.5.5 ASAP. Thanks again Allen and Philip, and also for your vote support jth :-)
Sorry to dredge up this old chestnut again, but I have finally gotten around to testing this using KOrganizer 3.5.5 from FC6 x86_64 rpms 3.5.5-0.2. The memory leak is indeed fixed. However, the appointment doesn't display correctly. For the test case attached, the VEVENT should appear on June 21 2006, but it does not. On the left hand side of the window where the month summaries are shown, every day is highlighted bold to indicate it has an event, but with the test file attached only one day should be highlighted. In the "What's next" view, I see 7 instances of the test appointment for midnight with no associated date. In the "list" view I see a single instance of the test appointment with only start and end times, no start or end dates. The appointment does not show up on June 21 for Day, Week or Month views. Thinking this may be due to the file being invalid for not containing an end date I took at a look at RFC#2445 http://www.ietf.org/rfc/rfc2445.txt and note that in section 4.8.2.4 "Date/Time Start" it mentions: "Events can have a start date/time but no end date/time. In that case, the event does not take up any time." Which I read to mean that not having an end date should be quite valid, and the appointment should show up on that day but without an associated time. As it stands, it appears that the event takes up infinite time! From the patch that was submitted, I gather that if the enddate is not valid we simply don't add it to the month view - wouldn't it be "more correct" to instead assume the end date, if not defined, is equal to the start date? The way I read it end dates are generally optional, so if missing one should assume they match the start date. I haven't reopened this bug as I wanted to get an opinion on wether this should be raised as a separate bug or in this one - please let me know which way to go.
I can confirm Ashley's observations on an i386 machine.
KOrganizer supports events with no end date, if the end date is not present it assumes end=start. About your problem, I had a look at RFC2445 and it seems DATETIME does not exist, it's DATE-TIME. Try: DTSTART;VALUE=DATE-TIME:20060621T000000 instead of: DTSTART;VALUE=DATETIME:20060621T000000 Can we close this crash report then?
Closing as the memory leak is fixed and the side issues are invalid.