2000460 - Thunderbird freezing, "not responding" for about 20 seconds, related to calendar calculateDates in CalRecurrenceInfo

Status: RESOLVED INCOMPLETE

(Calendar :: General, defect)

Description

[Elias Rudberg]

Attachment: thunderbird-profile.png

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:140.0) Gecko/20100101 Firefox/140.0

Steps to reproduce:

Using Thunderbird with a CALDAV calendar configured.

The calendar has some recurring events in it.

Actual results:

Thunderbird frequently freezing, "Not responding" for about 20 seconds, then starts working again.

Performance profiling shows that Thunderbird during about 20 seconds spent 100% of its time in "calculateDates", at "resource:///modules/CalRecurrenceInfo.sys.mjs:472:17"

Apparently it was repeating that 19322 times during those 20 seconds, so about 1000 times every second.

Attaching a screenshot showing some profiling results.

I have a CALDAV calendar configured and that does have some recurring events, including some events that are recurring "forever", for example one hour every Thursday from 8 to 9, without any "until" so there is no end date. I can imagine how that could give trouble depending on how it's implemented, for example if Thunderbird tries to make a list of all future recurrencies for a given calendar event, then that would be infinite so there would need to be limited to some time window, and if that window is too large then things would get slow. But that is just me speculating, I don't know how it's implemented, only that it seems to freeze due to excessive work in that "CalRecurrenceInfo" part of the code.

Expected results:

What should have happened is that Thunderbird should have continued working normally, not freezing, without any "Not responding" window popping up.

Comment 1

[Wayne Mery (:wsmwk)]

It might be one of these https://mzl.la/3XxKCOw

Comment 2

[Richard Leger]

Hi,

@Elias,
If you can reproduce the issue easily, would you be able to run a mozregression (https://mozilla.github.io/mozregression) to help identify the culprit was introduced?

@Wayne,
Could it be linked to any of those changes?
Bug 1890975 - https://hg-edge.mozilla.org/comm-central/rev/8af9d0761d67
Bug 1787677 - https://hg-edge.mozilla.org/comm-central/rev/1c7efffeefd758dbedaa6573d098d08707ec07cc

or any other changes in CalRecurrenceInfo
https://hg-edge.mozilla.org/comm-central/log?rev=CalRecurrenceInfo

Cheers,

Comment 3

[Wayne Mery (:wsmwk)]

(In reply to Richard Leger from comment #2)

@Wayne,
Could it be linked to any of those changes?
Bug 1890975 - https://hg-edge.mozilla.org/comm-central/rev/8af9d0761d67
Bug 1787677 - https://hg-edge.mozilla.org/comm-central/rev/1c7efffeefd758dbedaa6573d098d08707ec07cc

or any other changes in CalRecurrenceInfo
https://hg-edge.mozilla.org/comm-central/log?rev=CalRecurrenceInfo

Unclear. We also have staggering number of performance bug reports https://mzl.la/4pn8nEv in the past 3 years.

Comment 4

[Wayne Mery (:wsmwk)]

(In reply to Richard Leger from comment #2)

Hi,

@Elias,
If you can reproduce the issue easily, would you be able to run a mozregression (https://mozilla.github.io/mozregression) to help identify the culprit was introduced?

Elias can you find the regression range?

Comment 5

[Elias Rudberg]

(In reply to Wayne Mery (:wsmwk) from comment #4)

(In reply to Richard Leger from comment #2)

Hi,

@Elias,
If you can reproduce the issue easily, would you be able to run a mozregression (https://mozilla.github.io/mozregression) to help identify the culprit was introduced?

Elias can you find the regression range?

Hello, thanks for looking at this!

Unfortunately I cannot reproduce the issue any longer, but I have some idea about what kind of situation caused it: when I had the problem, I looked through the different events that were in the calendar and I found one specific event that looked strange, it had many many (like hundreds) "Reminder" lines.

Normally when double-clicking on an event a window is shown with onfo about that event, that window shows "Title", "Start Date", "End Date", "Repeat", and "Reminder" info for the event. The "Reminder" info can look for example like this:

"Reminder: 1 hour before the event starts"

But for this specific event that was in my calendar when the performance issue was happening, there were many such "Reminder" lines. It looked like this:

Reminder: 1 hour before the event starts
Reminder: 1 hour before the event starts
Reminder: 1 hour before the event starts
Reminder: 1 hour before the event starts
Reminder: 1 hour before the event starts
Reminder: 1 hour before the event starts
Reminder: 1 hour before the event starts
Reminder: 1 hour before the event starts
Reminder: 1 hour before the event starts
Reminder: 1 hour before the event starts
...
... and so on, many many such lines ...

I wish now that I had saved a copy of that .ics file before deleting that event, but unfortunately I did not save it, I just removed the strange calendar event. And after I had removed that event, the performance problem went away.

So, my theory is that the problem had to do with one specific event that was in my calendar, a recurring event that for some reason had multiple instances of "reminder" info in it. I don't know how that had happened and I am now unable to create such an event again. It could happen that the event had been created using another calendar client program This calendar is a CalDAV calendar on a server with a few different people connecting to it, those people are using different programs to add events and apparently one of those programs had added the unusual event that gave this performance problem.

If that theory is correct, then what would be needed to make Thunderbird handle it better is to improve how unusual or malformed calendar entries are processed. For example, if there are multiple instances of "reminder" info, only process the first one and ignore the rest (or similar).

Anyway, I'm sorry I cannot reproduce it anymore at the moment. If the problem appears again I will try to save the calendar contents to be able to reproduce it.

Comment 6

[Wayne Mery (:wsmwk)]

Elias,
Thanks for the update