1789999 - Thunderbird pauses for 10-15 seconds at a time, even for minutes. Stuck in icaltimezone_compare_change_fn of icaltime_compare of ical.js

Status: RESOLVED FIXED

(Calendar :: ICAL.js Integration, defect, P2)

Description

[Gabriele Svelto [:gsvelto]]

Since upgrading to Thunderbird 102.2.2 I've been experiencing long annoying pauses which sometimes go on for minutes but are usually in the 10-15 seconds range. I managed to capture a profile of one these hangs and it seems to be happening in the calendar code, possibly sorting dates:

https://share.firefox.dev/3Qu4goQ

Comment 1

[Wayne Mery (:wsmwk)]

gsvelto, Can you narrow this down to a specific aspect (type of calendar event) of a specific calendar?

A specific slice is https://profiler.firefox.com/public/phq3efb38de2ejnyw426285vm2d54b9kyb2afkg/calltree/?globalTrackOrder=0w3&hiddenGlobalTracks=1w3&hiddenLocalTracksByPid=25213-0we&implementation=js&range=16152m17898&thread=0&v=7

Comment 2

[Magnus Melin [:mkmelin]]

As a workaround you can try setting calendar.icaljs to false.

Comment 3

[Gabriele Svelto [:gsvelto]]

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

gsvelto, Can you narrow this down to a specific aspect (type of calendar event) of a specific calendar?

A specific slice is https://profiler.firefox.com/public/phq3efb38de2ejnyw426285vm2d54b9kyb2afkg/calltree/?globalTrackOrder=0w3&hiddenGlobalTracks=1w3&hiddenLocalTracksByPid=25213-0we&implementation=js&range=16152m17898&thread=0&v=7

I have a single Google calendar setup for my @mozilla.com account, and nothing else. Over the years it has accumulated a lot of events, probably hundreds of them.

Comment 4

[Gabriele Svelto [:gsvelto]]

This seems to be happening while the calendar syncs. If I force a sync by hand I immediately get a hang.

Comment 5

[Gabriele Svelto [:gsvelto]]

(In reply to Magnus Melin [:mkmelin] from comment #2)

As a workaround you can try setting calendar.icaljs to false.

I've changed that pref and indeed I experience no pauses anymore.

Comment 6

[Wayne Mery (:wsmwk)]

Lasana, Sean,
Is comment 1's profile sufficient information to attempt a fix?

Comment 7

[Geoff Lankow (:darktrojan)]

The profile suggests to me that something has a date very far in the future. Most of the time is spent in ICAL.Timezone._ensureCoverage which would be problematic if the argument was a high value, e.g. if an extra digit was accidentally added. I've never seen a profile with jank in this function before.

Comment 8

[Geoff Lankow (:darktrojan)]

Hmm, that function stops at the year 2035. So my previous comment is quite likely invalid.

Comment 9

[Gabriele Svelto [:gsvelto]]

I have a set of recurring events which have no end date AFAIK, maybe that could be related?

Comment 10

[Diomidis Spinellis]

I seem to be experiencing the same problem with version 102.2.2. I have uploaded a performance profile at https://share.firefox.dev/3RXmGzu. The issue is apparent in the 30" interval at its end with 100% CPU load. The culprit seems to be icaltimezone_compare_change_fn.

• The freezes occur every 60" and last for about 110".
• I don't think I'm auto-synchronizing with an external calendar.
• The freezes also occur in Safe Mode.
• Setting calendar.icaljs to false seems to stop the problem after restarting Thunderbird.
• My exported calendar is about 4MB large containing about 6000 VEVENT entries and 50 TODO items.

I went through the file looking for entries that could be triggering the behavior. One thing that struck me was numerous birthday entries with DTSTART/DTEND in 2037, as in the following example. Not sure if this is normal.

BEGIN:VEVENT
CREATED:20220727T213505Z
LAST-MODIFIED:20220912T071006Z
DTSTAMP:20220912T071006Z
UID:17cdb7a4-4579-4985-8523-979a07e99fc3
SUMMARY:John Doe. Birthday
RRULE:FREQ=YEARLY;UNTIL=20361231
DTSTART;TZID=Europe/Athens;VALUE=DATE:20370101
DTEND;TZID=Europe/Athens;VALUE=DATE:20370102
CLASS:PUBLIC
END:VEVENT

Comment 11

[Geoff Lankow (:darktrojan)]

(In reply to Gabriele Svelto [:gsvelto] from comment #9)

I have a set of recurring events which have no end date AFAIK, maybe that could be related?

So do I, and no problem here. I wouldn't expect

Could you increase the value of ICAL.Timezone.MAX_YEAR (either by changing the code in a local build or importing resource:///modules/calendar/Ical.jsm) and see what happens? I found a way to trigger a similar slowdown, and increasing the value helped. It'd also be interesting to know what value _ensureCoverage is being called with.

Comment 12

[Gabriele Svelto [:gsvelto]]

I can try making a local build and seeing if I can repro.

Comment 13

[Wayne Mery (:wsmwk)]

https://www.reddit.com/r/Thunderbird/comments/x39f0n/comment/iog68a1/?utm_source=reddit&utm_medium=web2x&context=3 also has a performance profile https://share.firefox.dev/3L7MZAJ

Comment 14

[Gabriele Svelto [:gsvelto]]

Sharing something that might be useful: my wife's Thunderbird installation has no calendars configured yet the workaround in comment 2 made the problem go away. This user on Reddit also mentioned he doesn't have any calendars but the workaround seems to have helped. This seems quite odd, doesn't it?

Comment 15

[Geoff Lankow (:darktrojan)]

I made a build of Thunderbird 102.2.2 with the value changed, if you wish to try them:

• Linux https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/E8rQEBpnRASVhT-88ZJYmQ/runs/0/artifacts/public/build/target.tar.bz2
• Mac https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/Tq_eRplrQFu4Sh45FKLi0g/runs/0/artifacts/public/build/target.dmg
• Windows https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/fWhh3289Qf2eHiAd_cEClw/runs/0/artifacts/public/build/target.zip

It seems very odd that no calendars configured would cause this. It suggests there might be something in the UI trying to do something beyond 2035, which wouldn't really surprise me but I don't know what it could be. I was able to make some things very slow just by pushing the date past 2035 and that is cleared up by this change. If somebody can get a full stack trace of the function acting slowly that would be a great help, even if we can solve the problem by changing the maximum year.

Comment 16

[Geoff Lankow (:darktrojan)]

Okay, I now understand why this function is being called so often even though 2035 is a long time from now. I also don't see any downside to removing the maximum year constraint.

Comment 17

[Geoff Lankow (:darktrojan)]

Attachment: Bug 1789999 - Remove MAX_YEAR constant for expanding timezones. r=#thunderbird-reviewers

This code doesn't do anything except avoid necessary calculation, and because the calculation isn't done the expensive part of the function is called over and over again.

Comment 18

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/6a451262bdac
Remove MAX_YEAR constant for expanding timezones. r=mkmelin

Comment 19

[Arthur K. (he/him)]

Possibly a dupe of bug 1780973?

Comment 20

[Wayne Mery (:wsmwk)]

(In reply to Arthur K. (he/him) from comment #19)

Possibly a dupe of bug 1780973?

Does the try build or current beta 106 solve it?

Comment 21

[Wayne Mery (:wsmwk)]

gsvelto, does the try build help you?

And,....

(In reply to Gabriele Svelto [:gsvelto] from comment #14)

Sharing something that might be useful: my wife's Thunderbird installation has no calendars configured yet the workaround in comment 2 made the problem go away.

Does the try build help that situation also? If not, please create a new bug report with a profile. Thanks

Comment 22

[Arthur K. (he/him)]

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

(In reply to Arthur K. (he/him) from comment #19)

Possibly a dupe of bug 1780973?

Does the try build or current beta 106 solve it?

Sadly, no. I'm in the midst of trying to capture a perf profile to add to 1780973 but TB's locked up good.

I managed to capture a perf profile over in bug 1780973 (https://share.firefox.dev/3dw9x1x) in case there's a relationship to this bug.

Comment 24

[Martin Schröder [:mschroeder]]

Is this something that needs to/should be brought upstream to ical.js?

Comment 25

[Geoff Lankow (:darktrojan)]

Comment on attachment 9295208 [details]
Bug 1789999 - Remove MAX_YEAR constant for expanding timezones. r=#thunderbird-reviewers

[Approval Request Comment]
Regression caused by (bug #): ical.js
User impact if declined: big perf impact if dealing with dates beyond 2031
Testing completed (on c-c, etc.): in 106.0b1
Risk to taking this patch (and alternatives if risky): low

Comment 26

[Geoff Lankow (:darktrojan)]

(In reply to Martin Schröder [:mschroeder] from comment #24)

Is this something that needs to/should be brought upstream to ical.js?

Yes, but all PRs there are being blocked by the ES6 work so I haven't done it yet. Leaving the NI.

Comment 27

[Gabriele Svelto [:gsvelto]]

Sorry for the delay, I tried the build in comment 15 and I can confirm that the problem is gone! \o/

Comment 28

[Wayne Mery (:wsmwk)]

Comment on attachment 9295208 [details]
Bug 1789999 - Remove MAX_YEAR constant for expanding timezones. r=#thunderbird-reviewers

[Triage Comment]
approved for esr102

Comment 29

[Rob Lemley [:rjl]]

This patch needs a follow-up to set the upstream source comment to mention the pull request at https://github.com/kewisch/ical.js/pull/541.

Comment 30

[Rob Lemley [:rjl]]

Attachment: Bug 1789999 - Follow-up: Include PR information in reference to upstream source. r=darktrojan

Comment 31

[Rob Lemley [:rjl]]

Thunderbird 102.3.2:
https://hg.mozilla.org/releases/comm-esr102/rev/7dd3014487f0

Comment 32

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/4353e8935d04
Follow-up: Include PR information in reference to upstream source. r=darktrojan

Comment 33

[Rob Lemley [:rjl]]

Comment on attachment 9297188 [details]
Bug 1789999 - Follow-up: Include PR information in reference to upstream source. r=darktrojan

[Triage Comment]
Documentation only fix for Ical.jsm upstream information.

Comment 34

[Rob Lemley [:rjl]]

Thunderbird 106.0b5:
https://hg.mozilla.org/releases/comm-beta/rev/6a5695bc11f8

Comment 35

[Rob Lemley [:rjl]]

Thunderbird 102.3.2+ (102.4.0?)
https://hg.mozilla.org/releases/comm-esr102/rev/8d8b229caa5e