GNOME Bugzilla – Bug 781950
Calendar data getting reloaded every two seconds
Last modified: 2017-06-16 15:56:20 UTC
In "dbus-monitor --session" I can see gnome-shell sending requests for the calendar data roughly every two seconds: method call time=1493500351.580830 sender=:1.22 -> destination=:1.33 serial=3129 path=/org/gnome/Shell/CalendarServer; interface=org.gnome.Shell.CalendarServer; member=GetEvents int64 1490611680 int64 1494240480 boolean false method call time=1493500353.677095 sender=:1.22 -> destination=:1.33 serial=3130 path=/org/gnome/Shell/CalendarServer; interface=org.gnome.Shell.CalendarServer; member=GetEvents int64 1490611680 int64 1494240480 boolean false method call time=1493500355.769533 sender=:1.22 -> destination=:1.33 serial=3131 path=/org/gnome/Shell/CalendarServer; interface=org.gnome.Shell.CalendarServer; member=GetEvents int64 1490611680 int64 1494240480 boolean false 1.22 is gnome-shell and 1.33 is gnome-shell-calendar-server. In between these calls there are lots of other messages from e-d-s to gnome-shell-calendar-server etc. Not only is all this constant dbus traffic and parsing of calendar data causing a slight cpu load, it is also triggering memory leaks in both gnome-shell-calendar-server and all involved e-d-s calendar processes.
This issue stopped happening in May but can be triggered again by going back to April in the calendar, so it is related to some event in April. I've looked a bit more into this and this seems to be what happens: - After a GetEvents method call in gnome-shell-calendar-server all events from April get added to a uid -> appointment hash table via generate_instances_cb() - Then for some reason on_objects_added() is called and tries to look up the uid of the added objects in the hash table and if it fails schedules the emission of the Changed signal over dbus after a timeout of 2 seconds - The Changed signal causes gnome-shell to call GetEvents via dbus again This cycle is basically repeated forever and is caused by some uid not found in the hash table. The uid that triggers this issue belongs to this event: BEGIN:VEVENT UID:20170313T182024Z-13199-1000-1819-3@t420 DTSTAMP:20170313T182024Z DTSTART:20170327T070000 DTEND:20170327T110000 SUMMARY:Some Event SEQUENCE:3 CREATED:20170313T182024Z LAST-MODIFIED:20170313T182043Z END:VEVENT From the gnome-shell-calendar-server log after selecting April: 01:28:31.468: Handling GetEvents (since=1490610480, until=1494239280, force_reload=false) 01:28:31.474: Loading events since 20170327T102800Z until 20170508T102800Z The event is in floating time and my current timezone is CEST (the switch from CET to CEST was on March 26th, i.e. 1 day before the event in question). I've confirmed that the event is not added to the hash table in generate_instances_cb().
Created attachment 353275 [details] [review] calendar-server: Specify the timezone for the view query I've talked with Milan and he suggested that this could be an issue with the "occur-in-time-range? ..." query not specifying a timezone. The event in question is a floating time event which is interpreted according the timezone. If no timezone is specified for the query, UTC is used [1]. e_cal_client_generate_instances_sync() on the other hand uses the default timezone (CEST in this case). This results in the query including the event, whereas generate_instances does not include it, which triggers this endless loop. I've attached a patch to add the timezone to the query. [1] https://git.gnome.org/browse/evolution-data-server/tree/src/calendar/libedata-cal/e-cal-backend-sexp.c#n140
Review of attachment 353275 [details] [review]: OK
Pushed: https://git.gnome.org/browse/gnome-shell/commit/?id=a0140fb