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...
