Open Bug 377487 Opened 18 years ago Updated 26 days ago

Freeze (hang) on .ics file which has BYYEARDAY and BYDAY in an RRULE

Categories

(Calendar :: Internal Components, defect)

defect
Not set
critical

Tracking

(Not tracked)

People

(Reporter: ssitter, Unassigned)

References

Details

(Keywords: hang)

Attachments

(1 file)

Attached file testcase
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a4pre) Gecko/20070413 Calendar/0.6a1 Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.4pre) Gecko/20070413 Calendar/0.5pre The following .ics file with a BYYEARDAY and a BYDAY statement in an RRULE causes Sunbird to hang. It also hoses the profile, because when you try to start up Sunbird after killing the process, it no longer opens the application window -> dataloss. See Bug 356207 for a similar issue with BYMONTHDAY. Testcase was extracted from Google Calendar http://www.google.com/calendar/ical/german__de%40holiday.calendar.google.com/public/basic.ics BEGIN:VCALENDAR PRODID:-//Google Inc//Google Calendar 70.9054//EN VERSION:2.0 CALSCALE:GREGORIAN METHOD:PUBLISH X-WR-CALNAME:Deutsche Feiertage X-WR-TIMEZONE:America/Los_Angeles X-WR-CALDESC:2005 Calendar X-WR-RELCALID:"" BEGIN:VEVENT DTSTART;VALUE=DATE:20041117 DTEND;VALUE=DATE:20041118 RRULE:FREQ=YEARLY;BYYEARDAY=-40,-41,-42,-43,-44,-45,-46;BYDAY=WE DTSTAMP:20070414T101043Z UID:unu5j96pbcvu917ne951ltkqrc_ctin4rb1dp06grrcd5i62u9ecdgmopbechgn4bj7dtnm er355phmur8@google.com CLASS:PUBLIC CREATED:20060915T033500Z DESCRIPTION: LAST-MODIFIED:20061119T052325Z SEQUENCE:0 STATUS:CONFIRMED SUMMARY:Buß- und Bettag TRANSP:OPAQUE END:VEVENT END:VCALENDAR
Flags: blocking-calendar0.7?
According to my first investigations Sunbird is stuck in an infinite loop in icalrecur.c line 977 <http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/calendar/libical/src/libical/icalrecur.c&rev=1.10&mark=977-982#971> - the for loop calls expand_year_days(), - flags is set to 0x40 (1<<BY_DAY + 1<<BY_YEAR_DAY), - switch statement executes the default clause and returns - loop continues
Flags: blocking-calendar0.8+
Please leave setting blocking+ to release drivers. Use the wanted flag and set it to ?
Flags: blocking-calendar0.8+
Flags: wanted-calendar0.8+
Removing blocking-calendar0.7?, has already wanted-calendar0.8+.
Flags: blocking-calendar0.7?
OS: Windows 2000 → All
Hardware: PC → All
Version: Trunk → unspecified
Not going to happen for 0.8.
Flags: wanted-calendar0.8+ → wanted-calendar0.8-
I have just encountered this problem with an Outlook ics file created by the ical exporter. The problem causes either Sunbird or the Lightning plug-in to go into a loop at startup. The only cure is to delete the storage.sdb database file. As I have a large calendar to import I cannot contemplate doing a manual update, so implementation is halted until this is fixed or circumvented.
worth to test whether latest libical has fixed this...
Flags: wanted-calendar0.8- → wanted-calendar0.9+
(In reply to comment #8) > worth to test whether latest libical has fixed this... > How do I go about seeing if it has? As I am using pre-built binaries presumably I need a later build?
(In reply to comment #8) > worth to test whether latest libical has fixed this... Issue still exists using latest-trunk build that contains the libical fixes from Bug 394902. Tested with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008032819 Calendar/0.6a1.
Flags: wanted-calendar1.0+
Flags: wanted-calendar0.9+
Flags: blocking-calendar1.0?
With TB integration coming up, this bug has a potential for widespread dataloss - emails being composed could be lost due to the hang. Nominating for flag.
Flags: tb-integration?
If you take it that way, every hang is dataloss. The dataloss flag should be used for bugs that directly cause dataloss, not indirectly. Nevertheless this bug can still be confirmed using 1.0b7 or current trunk. I get exceptions in the recurrence info's getOccurrences, NS_ERROR_OUT_OF_MEMORY. I assume there is some endless loop in libical.
Keywords: dataloss
The error reported in Lightning 1.5a1 (BuildID: 20120211034038) for this test case is the same as in Bug 419490: Error: Component returned failure code: 0x8007000e (NS_ERROR_OUT_OF_MEMORY) [calIRecurrenceItem.getOccurrences] Source file: [...]/calendar-js/calRecurrenceInfo.js Line: 537
Lightning 2.6a1 with ical.js backend enabled will throw the following error: > Error: 'Error: Invalid BYYEARDAY rule' when calling method: [calIRecurrenceRule::getOccurrences] = NS_ERROR_XPC_JS_THREW_JS_OBJECT > Source file: .../calendar-js/calRecurrenceInfo.js > Line: 493 This looks incorrect because the RRULE seems valid and allowed according to RFC 5545.
Flags: tb-integration?
Flags: blocking-calendar1.0?
See Also: → 1384198

I had a problem connecting my iCalendar (Apple) calendar with Thunderbird, which I suspect is very similar to or the same problem as this bug. I can add and see different calendar names under my account with a CalDAV link. However, I cannot display any events on these calendars. When I try to add an event, it simply does nothing. When I check the debug console, I can see the following error:

NS_ERROR_XPC_JAVASCRIPT_ERROR_WITH_DETAILS: [JavaScript Error: "Invalid BYYEARDAY rule" {file: "resource:///modules/calendar/Ical.sys.mjs" line: 3921}]'[JavaScript Error: "Invalid BYYEARDAY rule" {file: "resource:///modules/calendar/Ical.sys.mjs" line: 3921}]' when calling method: [calIDateTime::compare] calItemUtils.sys.mjs:127
    checkIfInRange resource:///modules/calendar/utils/calItemUtils.sys.mjs:127
    start resource:///modules/CalMemoryCalendar.sys.mjs:453
    run resource:///modules/calendar/utils/calIteratorUtils.sys.mjs:77

I found a very recent update on ical.js's GitHub page that addresses this issue and provides a fix. The issue link: https://github.com/kewisch/ical.js/issues/730 and the related pull request link: https://github.com/kewisch/ical.js/pull/877

Can this version of ical.js be merged with the main branch of Thunderbird?

Kind regards.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: