Summary: | crash on parsing outlook event | ||
---|---|---|---|
Product: | [Frameworks and Libraries] Akonadi | Reporter: | Cyrille Dunant <cyrille.dunant> |
Component: | EWS Resource | Assignee: | kdepim bugs <kdepim-bugs> |
Status: | RESOLVED FIXED | ||
Severity: | crash | CC: | carl, krissn, winter |
Priority: | NOR | ||
Version First Reported In: | 6.1.2 | ||
Target Milestone: | --- | ||
Platform: | openSUSE | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
Cyrille Dunant
2024-08-24 08:47:02 UTC
A few observations: As a libical guy, I can see right away that the calendar string is invalid since it doesn't end with a "END:VCALENDAR\r\n" then looking in EwsFetchCalendarDetailJob::processItems() I see format.fromString(memcal, mimeContent); not being checked for a failure return and then properly handled. maybe something as simple as `if(!format.fromString(memcal, mimeContent) continue;` or somesuch anyway, I can't help test and I'm not up on Akonadi either. this one interested me because I thought it might point to a bug in libical. I don't that that's the case. I'm a mere user, but this is quite common, for whichever reason -- I have wayyy too many calendars and sadly some are outlook. But because it causes crashes, effectively it makes the ews calendar fetching fail (In reply to Allen Winter from comment #1) > A few observations: > > As a libical guy, I can see right away that the calendar string is invalid > since it doesn't end with a "END:VCALENDAR\r\n" > > then looking in EwsFetchCalendarDetailJob::processItems() I see > format.fromString(memcal, mimeContent); not being checked for a failure > return and then properly handled. > > maybe something as simple as > `if(!format.fromString(memcal, mimeContent) continue;` > or somesuch > > anyway, I can't help test and I'm not up on Akonadi either. > this one interested me because I thought it might point to a bug in libical. > I don't that that's the case. Sorry, I think it may still be in effect a parsing bug: the string is malformed, yes, but all the information is there, so it would be right, I think, to still be able to handle this case, as a matter of robustness. Of course, this is my opinion as a user, for what it's worth. This is a duplicate of Bug 491681 (based on the comment below by Allen Winter) A possibly relevant merge request was started @ https://invent.kde.org/pim/kdepim-runtime/-/merge_requests/183 Git commit 2c4d702e630e832237f02b762890ca8ed03bd08c by Daniel Vrátil. Committed on 13/09/2024 at 10:21. Pushed by dvratil into branch 'release/24.08'. Attempt to workaround EWS servers sometimes returning broken iCal Apparently it's a known issue that some versions of EWS (including Outlook365) in some situations return an invalid iCal that is missing the closing END:VCALENDAR entry. This causes the event to be missing at best or to crash the EWS code at worst. This workaround simply checks for presence of END:VCALENDAR in the response and if it's missing it will simply append it to the end. Related: bug 491681 FIXED-IN: 24.08.2 M +22 -2 resources/ews/calendar/ewsfetchcalendardetailjob.cpp https://invent.kde.org/pim/kdepim-runtime/-/commit/2c4d702e630e832237f02b762890ca8ed03bd08c It works for me, now with the patch. |