After upgrading to current sys-libs/timezone-data-2020b, the evolution calendar backend dumped core; evolution could only be started after manually disabling several calendar sources. In one local calendar, a crash could be avoided by replacing occurrences of TZID:/freeassociation.sourceforge.net/ by TZID:/softwarestudio.org/ but the crash also occurred with google calendars where the fix is not so easily done. I recompiled evolution and evolution-data-server to no avail. Finally, downgrading to sys-libs/timezone-data-2020a returned everything back to working state. Reproducible: Always
This is a known issue for dev-libs/glib with timezone-data-2020b defaulting to zic --slim instead of --fat or some such. I noted this in #gentoo-base at some point.
-b slim vs -b fat https://mail.gnome.org/archives/distributor-list/2020-October/msg00000.html
If it's a glib bug (yes?) can we just patch it? Looks like https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1683/diffs?commit_id=4a120c2e2e0a26e1cd5ce7cb4ebe906ef6d588d3 is a proposed fix. Otherwise we can mask sys-libs/timezone-data-2020b for the time being.
though that one doesn't really talk about crashes, just very wrong timezones, etc
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=2f096dd2c9d8bbfad8489b8b35ae69cb00fbad3f commit 2f096dd2c9d8bbfad8489b8b35ae69cb00fbad3f Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2020-10-10 23:27:43 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2020-10-10 23:28:31 +0000 profiles/package.mask: mask >=timezone-data-2020b for cashes Reported-by: Bernd Feige Bug: https://bugs.gentoo.org/747538 Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> profiles/package.mask | 5 +++++ 1 file changed, 5 insertions(+)
Created attachment 664834 [details] Minimal .ics file with timezones and one event causing the crash Since there were doubts on whether a crash could occur, I attach an .ics file leading to the crash (calendar/system/calendar.ics). In gdb the trace looks like this: > gdb evolution ... Thread 23 "pool-evolution" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fff8bfff640 (LWP 79355)] 0x00007ffff3d72291 in ?? () from /lib64/libc.so.6 (gdb) where #0 0x00007ffff3d72291 in () at /lib64/libc.so.6 #1 0x00007ffff23b1009 in icalrecur_iterator_new () at /usr/lib64/libical.so.3 #2 0x00007ffff755bb56 in i_cal_recur_iterator_new () at /usr/lib64/libical-glib.so.3 #3 0x00007ffff0397c08 in e_cal_recur_generate_instances_sync () at /usr/lib64/libecal-2.0.so.1 #4 0x00007ffff0379df7 in () at /usr/lib64/libecal-2.0.so.1 #5 0x00007ffff03805d8 in e_cal_client_generate_instances_for_object_sync () at /usr/lib64/libecal-2.0.so.1 #6 0x00007fffe6613769 in () at /usr/lib64/evolution/libevolution-calendar.so #7 0x00007fffe66110ec in () at /usr/lib64/evolution/libevolution-calendar.so #8 0x00007ffff72489b4 in () at /usr/lib64/libglib-2.0.so.0 #9 0x00007ffff72480ed in () at /usr/lib64/libglib-2.0.so.0 #10 0x00007ffff3ddfe6e in start_thread () at /lib64/libpthread.so.0 #11 0x00007ffff3d1109f in clone () at /lib64/libc.so.6
(In reply to Bernd Feige from comment #6) > Created attachment 664834 [details] > Minimal .ics file with timezones and one event causing the crash > > Since there were doubts on whether a crash could occur, I attach an .ics > file leading to the crash (calendar/system/calendar.ics). In gdb the trace > looks like this: > > gdb evolution > ... > Thread 23 "pool-evolution" received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0x7fff8bfff640 (LWP 79355)] > 0x00007ffff3d72291 in ?? () from /lib64/libc.so.6 > (gdb) where > #0 0x00007ffff3d72291 in () at /lib64/libc.so.6 > #1 0x00007ffff23b1009 in icalrecur_iterator_new () at > /usr/lib64/libical.so.3 > #2 0x00007ffff755bb56 in i_cal_recur_iterator_new () at > /usr/lib64/libical-glib.so.3 > #3 0x00007ffff0397c08 in e_cal_recur_generate_instances_sync () at > /usr/lib64/libecal-2.0.so.1 > #4 0x00007ffff0379df7 in () at /usr/lib64/libecal-2.0.so.1 > #5 0x00007ffff03805d8 in e_cal_client_generate_instances_for_object_sync () > at /usr/lib64/libecal-2.0.so.1 > #6 0x00007fffe6613769 in () at > /usr/lib64/evolution/libevolution-calendar.so > #7 0x00007fffe66110ec in () at > /usr/lib64/evolution/libevolution-calendar.so > #8 0x00007ffff72489b4 in () at /usr/lib64/libglib-2.0.so.0 > #9 0x00007ffff72480ed in () at /usr/lib64/libglib-2.0.so.0 > #10 0x00007ffff3ddfe6e in start_thread () at /lib64/libpthread.so.0 > #11 0x00007ffff3d1109f in clone () at /lib64/libc.so.6 That looks promising. Might be a dev-libs/libical bug or evolution bug in calling dev-libs/libical. If you build dev-libs/libical with FEATURES='nostrip' (or FEATURES='splitdebug') and -ggdb added to CFLAGS/CXXFLAGS you should be able to get line numbers where crash happens.
(In reply to Sergei Trofimovich from comment #7) > That looks promising. Might be a dev-libs/libical bug or evolution bug in > calling dev-libs/libical. > > If you build dev-libs/libical with FEATURES='nostrip' (or > FEATURES='splitdebug') and -ggdb added to CFLAGS/CXXFLAGS you should be able > to get line numbers where crash happens. Like this? Thread 73 "pool-evolution" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7ffeecf6c640 (LWP 2707384)] 0x00007ffff3d71291 in ?? () from /lib64/libc.so.6 (gdb) where #0 0x00007ffff3d71291 in () at /lib64/libc.so.6 #1 0x00007ffff23aff97 in initialize_rscale (impl=0x7ffed000b940) at /var/tmp/portage/dev-libs/libical-3.0.8/work/libical-3.0.8/src/libical/icalrecur.c:1370 #2 icalrecur_iterator_new (rule=..., dtstart=...) at /var/tmp/portage/dev-libs/libical-3.0.8/work/libical-3.0.8/src/libical/icalrecur.c:1919 #3 0x00007ffff755b06b in i_cal_recur_iterator_new (rule=0x7fffc80226b0, dtstart=<optimized out>) at src/libical-glib/i-cal-recur-iterator.c:87 #4 0x00007ffff0392c08 in e_cal_recur_generate_instances_sync () at /usr/lib64/libecal-2.0.so.1 #5 0x00007ffff0374df7 in () at /usr/lib64/libecal-2.0.so.1 #6 0x00007ffff037b5d8 in e_cal_client_generate_instances_for_object_sync () at /usr/lib64/libecal-2.0.so.1 #7 0x00007fffe660c769 in () at /usr/lib64/evolution/libevolution-calendar.so #8 0x00007fffe660a0ec in () at /usr/lib64/evolution/libevolution-calendar.so #9 0x00007ffff72479b4 in () at /usr/lib64/libglib-2.0.so.0 #10 0x00007ffff72470ed in () at /usr/lib64/libglib-2.0.so.0 #11 0x00007ffff3ddee6e in start_thread () at /lib64/libpthread.so.0 #12 0x00007ffff3d1009f in clone () at /lib64/libc.so.6
Yeah, looks about right. static int initialize_rscale(icalrecur_iterator *impl) { struct icalrecurrencetype rule = impl->rule; struct icaltimetype dtstart = impl->dtstart; char locale[ULOC_KEYWORD_AND_VALUES_CAPACITY] = ""; UErrorCode status = U_ZERO_ERROR; UChar *tzid = (UChar *) UCAL_UNKNOWN_ZONE_ID; short is_hebrew = 0; if (dtstart.zone) { /* Convert the UTF8 timezoneid of dstart to ICU UChar. */ const char *src = icaltimezone_get_tzid((icaltimezone *) dtstart.zone); size_t len = (strlen(src) + 1) * U_SIZEOF_UCHAR; // <- crashes here If you build dev-libs/libical with -ggdb3 in CFLAGS you can poke in gdb at the values of 'impl', 'rule' and 'dtstart'. Perhaps 'dtstart.zone' is not initialized. I guess it's normally initialized in icaltimezone_load_builtin_timezone(): https://github.com/libical/libical/blob/e64e5bff29b74830b2b490e000d67914573569ba/src/libical/icaltimezone.c#L1779 That probably calls icaltzutil_fetch_timezone(): https://github.com/libical/libical/blob/4f8a21305f65ef8145775b5ad1428b3a72fc71de/src/libical/icaltz-util.c#L265 which implements tzdata file parsing directly if I read it correctly. It probably needs an update to handle new format. Would be nice to have a smaller program against libical to report it upstream.
Meanwhile I tried to install evolution and import minimal calendar. What should I do to observe the crash? I imported calendar from existing file and clecked on it, but all I see is the warning about calendar parse failures. Should I try to create something in it?
(In reply to Sergei Trofimovich from comment #10) > Meanwhile I tried to install evolution and import minimal calendar. What > should I do to observe the crash? > > I imported calendar from existing file and clecked on it, but all I see is > the warning about calendar parse failures. Should I try to create something > in it? Okay, it appears to be more complicated. The minimal ICS does not by itself cause a segfault but when I try to enable the personal calendar with it, it simply becomes deselected again. So some errors appear to be captured in evolution. I reliably get the crash when enabling my google calendar. Debugging the fault I get the following: In /var/tmp/portage/dev-libs/libical-3.0.8/work/libical-3.0.8/src/libical/icalrecur.c:1369, const char *src = icaltimezone_get_tzid((icaltimezone *) dtstart.zone); src is NULL. Therefore the segfault in the strlen() in the next line. print(*dtstart.zone) {tzid = 0x0, location = 0x5555564c70d0 "Europe/Berlin", tznames = 0x0, latitude = 52.516388888888891, longitude = 13.366666666666667, component = 0x0, builtin_timezone = 0x0, end_year = 2025, changes = 0x555556501110} I looked a bit further and have the impression that there is a parse error in icaltimezone_load_builtin_timezone() (icaltimezone.c line 1859). I could try to isolate the single event in the google calendar triggering the segfault. But actually I think there must be a glaring problem with libical's handling of timezone-data-2020b errors. The first observation with it was that evolution-data-server was using up all processor resources on my laptop, which I could fix by the described TZID fix. I think the minimal ICS file does trigger a variant of the problem, just not leading to a crash and therefore harder to isolate...
(In reply to Sergei Trofimovich from comment #3) > If it's a glib bug (yes?) can we just patch it? > > Looks like > https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1683/ > diffs?commit_id=4a120c2e2e0a26e1cd5ce7cb4ebe906ef6d588d3 is a proposed fix. > > Otherwise we can mask sys-libs/timezone-data-2020b for the time being. I patched glib with this small patch but while it definitively looks like better to have :-) it did not change the errors with evolution (calendars get disabled) and ultimatively the crash I'm experiencing. BTW, my localtime is: /etc/localtime -> ../usr/share/zoneinfo/Europe/Berlin
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3cec5bd675c583b39c72eb2df45bc8f2ea342a12 commit 3cec5bd675c583b39c72eb2df45bc8f2ea342a12 Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2020-10-29 07:55:46 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2020-10-29 07:59:27 +0000 sys-libs/timezone-data: add USE=zic-slim (disable by default) Many programs can't handle "slim" format of /usr/share/zoneinfo. Expose an USE flag to allow ease switching back and forth while using up to date zoneinfo data. Bug: https://bugs.gentoo.org/749591 Bug: https://bugs.gentoo.org/747538 Package-Manager: Portage-3.0.8, Repoman-3.0.2 Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> sys-libs/timezone-data/metadata.xml | 4 ++++ sys-libs/timezone-data/timezone-data-2020d.ebuild | 7 ++++++- 2 files changed, 10 insertions(+), 1 deletion(-)
(In reply to Bernd Feige from comment #12) > (In reply to Sergei Trofimovich from comment #3) > > If it's a glib bug (yes?) can we just patch it? > > > > Looks like > > https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1683/ > > diffs?commit_id=4a120c2e2e0a26e1cd5ce7cb4ebe906ef6d588d3 is a proposed fix. > > > > Otherwise we can mask sys-libs/timezone-data-2020b for the time being. > > I patched glib with this small patch but while it definitively looks like > better to have :-) it did not change the errors with evolution (calendars > get disabled) and ultimatively the crash I'm experiencing. > Please also have a look at bug 751784 and apply the second glib fix from there. It has fixed a xfce4 panel clock applet DST issue for me.
I can confirm that sys-libs/timezone-data-2020d with default -zic-slim fixes the crash and calendar disabling in evolution. I have also confirmed that both still occur if it is compiled with zic-slim - thanks for the good work! (In reply to Maciej S. Szmigiero from comment #14) > Please also have a look at bug 751784 and apply the second glib fix from > there. > > It has fixed a xfce4 panel clock applet DST issue for me. I applied it, but it did not fix evolution with sys-libs/timezone-data +zic-slim - would have been nice if this was the culprit. Apparently there are different places to fix...
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=2d1d2edfcb95e639a4607131f175565c0ad6e699 commit 2d1d2edfcb95e639a4607131f175565c0ad6e699 Author: Sam James <sam@gentoo.org> AuthorDate: 2025-03-23 00:53:46 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2025-03-23 00:54:42 +0000 sys-libs/timezone-data: go back to fat data dateutil still isn't ready. Bug: https://bugs.gentoo.org/747538 Bug: https://github.com/dateutil/dateutil/issues/1059 Bug: https://github.com/dateutil/dateutil/pull/1091 Bug: https://github.com/dateutil/dateutil/pull/1130 Signed-off-by: Sam James <sam@gentoo.org> sys-libs/timezone-data/timezone-data-2025b.ebuild | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=26f5043aa181a4148c7ed3fa58a9890fbb8e3fb2 commit 26f5043aa181a4148c7ed3fa58a9890fbb8e3fb2 Author: Sam James <sam@gentoo.org> AuthorDate: 2025-03-23 00:13:02 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2025-03-23 00:54:41 +0000 sys-libs/timezone-data: add 2025b Enable zic-slim by default too, following the upstream default. It's been 4.5 years since it was introduced and the breakage in the ecosystem should be sorted now. Ruby's tzinfo gem was fixed in November 2020, libical was fixed in March 2021, glib was fixed back in October 2020. Bug: https://bugs.gentoo.org/747538 Signed-off-by: Sam James <sam@gentoo.org> sys-libs/timezone-data/Manifest | 1 + sys-libs/timezone-data/timezone-data-2025b.ebuild | 170 ++++++++++++++++++++++ 2 files changed, 171 insertions(+)
