| Summary: | KOrganizer crashes when using caldav calendar | ||
|---|---|---|---|
| Product: | [Applications] korganizer | Reporter: | bugzy <bugzylittle> |
| Component: | general | Assignee: | kdepim bugs <kdepim-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | crash | CC: | kdenis, onkekabonke, wbauer1, winter |
| Priority: | NOR | Keywords: | drkonqi |
| Version: | 5.7.3 | ||
| Target Milestone: | --- | ||
| Platform: | Fedora RPMs | ||
| OS: | Linux | ||
| Latest Commit: | https://cgit.kde.org/eventviews.git/commit/?h=Applications/17.12&id=a3a66bb10020e6fbdd354b4ecc6c0fee6741c467 | Version Fixed In: | 5.8.0 |
| Attachments: |
Todo Calendar fentry that crashes korganizer
terminal output on delete of bad entry |
||
|
Description
bugzy
2018-04-12 18:51:56 UTC
Created attachment 111994 [details]
Todo Calendar fentry that crashes korganizer
After finding a way to disable my calendar collections and re-enable each calendar one by one, I was able to narrow down the cause of the crash to the attached vtodo entry. I copied the contents of the entry using akonadiconsole and pasted it in the attached file.
Created attachment 111995 [details]
terminal output on delete of bad entry
After deleting the entry directly from akonadiconsole, the line in the attached file appeared in the terminal. Not sure if it will be helpful in diagnosing the issue.
The last point to note is that I am able to reproduce the crash whenever I re-import the attached todo entry. Steps to reproduce: 1. Download Attached Todo calendar entry 2. Import the entry and "merge" to existing calendar. 3. Close korganizer (or kontact). 4. Open korganizer. Expected Results: korganizer opens properly Actual results: korganizer crashes Deleting the bad entry fixes the issue but just wanted to document this behavior here. Thanks Works fine for me with KOrganizer master and libical 3.0.x which libical version are you using? I have libical 2.0, specifically libical-2.0.0-13.fc27.x86_64 does the crash only happen in month view? i.e. can you also test agenda or todo views? None of the other views work. The only solution to get things functional again is to disable the calendar with the problem. Additional Information: - All my calendars are webdav calendars synced using nextcloud to my various devices. - I should mention that the faulty todo entry was created using Zanshin. I did not think that was relevant until I added some new todo items yesterday and began experiencing the same problem. I use Zanshin at work and Kontact with Korganizer on laptop and home PC. I was able to find and fix the actual cause of the problem by running the "calendarjanitor" tool. The tool found an orphaned TODO entry in the affected calendar. It turns out that whenever I added a new entry into the affected calendar, the orphaned TODO would cause korganizer to crash when parsing that calendar. So my new entries (attached above) were not the problem, I was simply adding new entries to a faulty calendar:
==Output of calendarjanitor (default scan mode):==
Checking for orphans... [!!]
The following incidences are children of nonexistent parents:
* Found buggy incidence:
id=159344; summary="Set in plant dividers for garden in plot behind house"
DTSTART=invalid;
DTDUE=invalid;
In fix mode these children will be unparented.
Running the too in fix mode solved the problem and everything has been running smooth since then.
==Output of calendarjanitor --fix (fix mode):==
Checking for orphans... [!!]
The following incidences are children of nonexistent parents:
* Found buggy incidence:
id=159344; summary="Set in plant dividers for garden in plot behind house"
DTSTART=invalid;
DTDUE=invalid;
Children were successfully unparented.
The crash is probably fixed by https://cgit.kde.org/eventviews.git/commit/?h=Applications/17.12&id=a3a66bb10020e6fbdd354b4ecc6c0fee6741c467 I think. *** Bug 397314 has been marked as a duplicate of this bug. *** I think Wolfgang is right about this. According to https://phabricator.kde.org/source/eventviews/tags/master/;a3a66bb10020e6fbdd354b4ecc6c0fee6741c467 it is fixed in 18.04.0, which should be... 5.8.0, I guess? I still hate this superfluous pim extra versioning scheme... (In reply to Denis Kurz from comment #12) > it is fixed in 18.04.0, which > should be... 5.8.0, I guess? Yes, that's indeed 5.8.0. Actually the fix was pushed to the 17.12 branch as well, but that was after 17.12.3/5.7.3 so it didn't make it into any 17.12 (or 5.7.x) release. |