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

Status: UNCONFIRMED

(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?