Created attachment 1355104 [details]
File: backtrace

Created attachment 1355105 [details]
File: cgroup

Created attachment 1355106 [details]
File: core_backtrace

Created attachment 1355107 [details]
File: cpuinfo

Created attachment 1355108 [details]
File: dso_list

Created attachment 1355109 [details]
File: environ

Created attachment 1355110 [details]
File: limits

Created attachment 1355111 [details]
File: maps

Created attachment 1355112 [details]
File: mountinfo

Created attachment 1355113 [details]
File: open_fds

Created attachment 1355114 [details]
File: proc_pid_status

Created attachment 1355115 [details]
File: var_log_messages

Created attachment 1355116 [details]
File: exploitable

Thanks for a bug report. The backtrace shows that this crashed when evolution had been preloading Indian/Cocos timezone. I could not reproduce it initially, but after some tweaks I received the crash as well. It turned out that all of the following files are affected:

   /usr/share/zoneinfo/Indian/Cocos
   /usr/share/zoneinfo/Indian/Christmas
   /usr/share/zoneinfo/Pacific/Chuuk
   /usr/share/zoneinfo/Pacific/Pohnpei
   /usr/share/zoneinfo/Atlantic/South_Georgia
   /usr/share/zoneinfo/Pacific/Tarawa
   /usr/share/zoneinfo/Pacific/Port_Moresby
   /usr/share/zoneinfo/Pacific/Palau
   /usr/share/zoneinfo/Pacific/Funafuti
   /usr/share/zoneinfo/Pacific/Wake
   /usr/share/zoneinfo/Pacific/Wallis

When you move them out of the /usr/share/zoneinfo/ directory, then Evolution will start properly.

Looking more deeply into this it looks like the tzdata zones are broken in Fedora 27 and 28. They are, at least, different from those in Fedora 25 and 26, where these pairs match each other (27 and 28 are the same, 25 and 26 are the same, but 26 and 27 are different). The difference in 27/28 is that those versions lead to crash when libical tries to read them from /usr/share/zoneinfo/.

One of the affected timezones is India/Cocos.

The working version reports:

> (gdb) p type_cnts
> $2 = {ttisgmtcnt = "\000\000\000\001", ttisstdcnt = "\000\000\000\001",
>       leapcnt = "\000\000\000", timecnt = "\000\000\000",
>       typecnt = "\000\000\000\001", charcnt = "\000\000\000\006"}

where the important member is the typecnt, which is 1 here. The crashing version says:

> (gdb) p type_cnts
> $2 = {ttisgmtcnt = "\000\000\000\002", ttisstdcnt = "\000\000\000\002",
>       leapcnt = "\000\000\000", timecnt = "\000\000\000\002",
>       typecnt = "\000\000\000\002", charcnt = "\000\000\000\n"}

where the typecnt is 2. Looking into the libical sources where the timezones are shown as iCalendar objects this one reads:

   BEGIN:VCALENDAR
   PRODID:-//citadel.org//NONSGML Citadel calendar//EN
   VERSION:2.0
   BEGIN:VTIMEZONE
   TZID:/citadel.org/20171102_1/Indian/Cocos
   LAST-MODIFIED:20171102T203623Z
   X-LIC-LOCATION:Indian/Cocos
   X-PROLEPTIC-TZNAME:LMT
   BEGIN:STANDARD
   TZNAME:+0630
   TZOFFSETFROM:+0630
   TZOFFSETTO:+0630
   DTSTART:19700101T000000
   END:STANDARD
   END:VTIMEZONE
   END:VCALENDAR

which should correspond to tzdata 2017c information.

I've been comparing these tzdata-2017c builds:
f25: https://koji.fedoraproject.org/koji/buildinfo?buildID=991824
f26: https://koji.fedoraproject.org/koji/buildinfo?buildID=991823
f27: https://koji.fedoraproject.org/koji/buildinfo?buildID=991822
f28: https://koji.fedoraproject.org/koji/buildinfo?buildID=991821

As the result packages are noarch, I'd expect that the content of each of them will be exactly the same, regardless Fedora version being used to generate them. Or at least the binary files in the /usr/share/zoneinfo/ should be the same, otherwise the code which deciphers the binary content can easily fail, as it happened now.

I would pasting here the result of the diff of the noarch package content between f26 and f27 for completeness, but it reports 672 files, which is not suitable here. I unpacked the rpm content into f26 and f27 folders, then run:
   $ diff -upr f26 f27
and some of the top files are:
> Binary files f26/zoneinfo/Africa/Casablanca and f27/zoneinfo/Africa/Casablanca differ
> Binary files f26/zoneinfo/Africa/El_Aaiun and f27/zoneinfo/Africa/El_Aaiun differ
> Binary files f26/zoneinfo/America/Araguaina and f27/zoneinfo/America/Araguaina differ
and so on.

Please note that the koji versions of tzdata-2017b-1 for f26 and f27 are exactly the same [1][2], but when I rebuild them in koji today [3][4], then their content differs, while they are built from exactly the same sources.

Thus there changed something in the build system which breaks tzdata.

[1] https://koji.fedoraproject.org/koji/buildinfo?buildID=873220
[2] https://koji.fedoraproject.org/koji/buildinfo?buildID=873219
[3] https://koji.fedoraproject.org/koji/taskinfo?taskID=23297537
[4] https://koji.fedoraproject.org/koji/taskinfo?taskID=23297539

Further observations: the mass rebuild package content tzdata-2017b-2.fc27 [5] differs in content with the tzdata-2017b-1.fc27 [2]. It turns out it's zic, which generates the /usr/share/zoneinfo/ files. The tzdata doesn't use the one it has bundled, but the one provided by glib2-common (/usr/sbin/zic). The bundled zic.c version between 2017b and 2017c differs and when I use the buncled in 2017c in F26, then I can reproduce the issue too. That can be that the mass rebuild used new glibc and thus generates different output.

I'm still investigating this, I'll update this bug when I know more.

[5] https://koji.fedoraproject.org/koji/buildinfo?buildID=933471

Thanks for the update.

I compared zic.c from glibc-2.25.90-1.fc27 (the good one, having glibc-2.25-80-ga10e9c4 inside) and from glibc-2.25.90-28.fc27 (the bad one, having glibc-2.25-754-g00d7a37) and the locally built 'zic' run on tzdata-2017c one generates Indian/Cocos of size 160 (the good), the other one of size 191 (the bad). I made a single change in the bad zic.c file:

- enum { WORK_AROUND_QTBUG_53071 = true };
+ enum { WORK_AROUND_QTBUG_53071 = false };

and then they both generate the same Indian/Cocos file, size of 160.

It can be that the workaround for the QT bug [6] in zic.c uncovered an issue in libical tzfile decoder, I'm still investigating it.

[1] https://bugreports.qt.io/browse/QTBUG-53071

The workaround for the QTBUG is breaking libical 2.0, libical 3.0 doesn't crash, though it also doesn't look like the correctly parsed timezone (see below). The libical 3.0 is part of rawhide only and it cannot go to f27 or earlier, because it is not binary compatible with libical 2.0.

I used git checkout of libical at these states:
libical 2.0 is at commit 7f07ace91faa8b1d578bf5
libical master is at commit d0a9cba745282c895ff

Using old Indian/Cocos file (size is 160):

libical 2.0 with exact-vtimezones=0:
	BEGIN:VTIMEZONE
	TZID:/freeassociation.sourceforge.net/Indian/Cocos
	X-LIC-LOCATION:Indian/Cocos
	BEGIN:STANDARD
	TZNAME:+0630
	DTSTART:19700101T060000
	TZOFFSETFROM:+0630
	TZOFFSETTO:+0630
	END:STANDARD
	END:VTIMEZONE

libical 2.0 with exact-vtimezones=1:
	BEGIN:VTIMEZONE
	TZID:/freeassociation.sourceforge.net/Indian/Cocos
	X-LIC-LOCATION:Indian/Cocos
	BEGIN:STANDARD
	TZNAME:+0630
	DTSTART:19700101T000000
	TZOFFSETFROM:+0630
	TZOFFSETTO:+0630
	END:STANDARD
	END:VTIMEZONE

libical master:
	BEGIN:VTIMEZONE
	TZID:/freeassociation.sourceforge.net/Indian/Cocos
	X-LIC-LOCATION:Indian/Cocos
	BEGIN:STANDARD
	TZNAME:+0630
	DTSTART:19700101T000000
	TZOFFSETFROM:+0630
	TZOFFSETTO:+0630
	END:STANDARD
	END:VTIMEZONE

Using Indian/Cocos with applied workaround for QTBUG-53071 by `zic` (size is 191):

libical 2.0 with exact-vtimezones=0 (note of the second TZOFFSETFROM,
which looks like a garbage and running with asan, as `LD_PRELOAD=/usr/lib64/libasan.so.4 ./icaltz`,
leads to a crash):
	BEGIN:VTIMEZONE
	TZID:/freeassociation.sourceforge.net/Indian/Cocos
	X-LIC-LOCATION:Indian/Cocos
	BEGIN:STANDARD
	TZNAME:+0630
	DTSTART:19700117T090000
	RRULE:FREQ=YEARLY;BYDAY=3TU;BYMONTH=1
	TZOFFSETFROM:+0630
	TZOFFSETTO:+0630
	END:STANDARD
	BEGIN:DAYLIGHT
	TZNAME:+0630
	DTSTART:19701209T030000
	RRULE:FREQ=YEARLY;BYDAY=2SA;BYMONTH=12
	TZOFFSETFROM:+062740
	TZOFFSETTO:+0630
	END:DAYLIGHT
	END:VTIMEZONE

libical 2.0 with exact-vtimezones=1:
	BEGIN:VTIMEZONE
	TZID:/freeassociation.sourceforge.net/Indian/Cocos
	X-LIC-LOCATION:Indian/Cocos
	BEGIN:STANDARD
	TZNAME:+0630
	DTSTART:19700101T000000
	TZOFFSETFROM:+0630
	TZOFFSETTO:+0630
	END:STANDARD
	BEGIN:STANDARD
	TZNAME:+0630
	DTSTART:20380119T094407
	TZOFFSETFROM:+0630
	TZOFFSETTO:+0630
	END:STANDARD
	END:VTIMEZONE

libical master (see the DTSTART, which should be rather 1970):
	BEGIN:VTIMEZONE
	TZID:/freeassociation.sourceforge.net/Indian/Cocos
	X-LIC-LOCATION:Indian/Cocos
	BEGIN:STANDARD
	TZNAME:+0630
	DTSTART:20380117T094407
	TZOFFSETFROM:+0630
	TZOFFSETTO:+0630
	RRULE:FREQ=YEARLY;BYDAY=3TU;BYMONTH=1
	END:STANDARD
	END:VTIMEZONE

The thing is that the users of libical should use exact-vtimezones=0, because servers like Google do not accept those expanded timezones, they want those with RRULE.

Honestly, glibc should disable the workaround for the QTBUG, (it's QT which should be fixed, which the bug suggests is doable), especially when the workaround for QT breaks other libraries, like libical.

I'll ask libical developers to join the bug, or at least to give me their opinion and I'll eventually copy it here.

Created attachment 1357664 [details]
icaltz.c (reproducer)

Here's the reproducer for libical, with which I generated the output at the above comment. The first line of the file contains a command line how to compile & run it. As noted in the previous comment, to make it crash use for example:

   $ LD_PRELOAD=/usr/lib64/libasan.so.4 ./icaltz

when there is the "broken" Indian/Cocos timezone stored. This version works with libical 2.0. To have it compiled with libicl 3.0 comment the line with icaltzutil_set_exact_vtimezones_support() call, because that function had been removed in 3.0.

Created attachment 1357674 [details]
proposed (interim?) patch for tzdata package

This is a patch for tzdata package to disable the QTBUG workaround and to use provided zic in the tzdata release, which fixes the breakage of libical due to that workaround being applied. A side effect of this change is that the resulting /usr/share/zoneinfo/ files will be consistent across Fedora versions, regardless of what glibc version will be installed. That can be for good and for bad, it really depends.

Please, consider using this change until a consensus of the bug (and proper fix) is done. It should help to Fedora 27 users at least. If you think the change for tzdata package is not appropriate, then feel free to reject it.

ping Patsy, this is still an issue, which can be fixed, but there's not much interest?

Hi Milan, 

I'm reviewing this and will get back to you over the next few days.

Thanks for all of your analysis.

-Patsy

Hi Milan,

It looks like the QTBUG fix was added in tzdata-2016e.  Did you see this failure with any of the tzdata updates prior to tzdata-2017c?

If you look at the NEWS file for tzdata-2017c there were quite a few changes to zic in 2017c.

Just to be sure I understand the situation clearly:

This fails with both the glibc provided zic and the tzdata provided zic.  Is that correct?

Do you know if it failed with tzdata-2017b?

Thanks!
Patsy

To make it clear, the zic bundled with tzdata was/is not used in Fedora, because Fedora relies on zic provided by glibc. Thus any tzdata built with "patched" zic in glibc causes issues for libical pre-3.0.1 release.

> This fails with both the glibc provided zic and the tzdata provided zic.
> Is that correct?

libical fails with any zic which has the QTBUG workaround turned on, yes. The proposed patch disables the QTBUG workaround in bundled zic in tzdata and compiles that bundled zic, thus it's "deterministic" what output will be generated, regardless of used glibc version.

tzdata can not ship a version of zic that generates different output from the system provided zic.

We also can not ship a version of tzdata zic that deliberately breaks QT.

Perhaps libical could be modified to correctly handle the current zic output.

(In reply to Patsy Franklin from comment #27)
> tzdata can not ship a version of zic that generates different output from
> the system provided zic.
> 
> We also can not ship a version of tzdata zic that deliberately breaks QT.
> 
> Perhaps libical could be modified to correctly handle the current zic output.

As Fedora glibc lead I agree with Patsy.

I don't see a clear root cause analysis for why libical fails to load the binary time zone data files. The Qt workaround does not make the data files invalid, it simply alters them to work around a Qt bug, and a conforming application should still be able to read them.

In glibc we will not alter zic or change the defaults to disable compatibility with older Qt versions until upstream does so also (we rebase tzcode from upstream with Paul Eggert's help).

From a system perspective we want to have just one zic which is used by us and our customers for compiling timezone data.

(In reply to Patsy Franklin from comment #27)
> tzdata can not ship a version of zic that generates different output from
> the system provided zic.

Except it does that already. You build tzdata-2017c down to Fedora 25, but the zic version in the tzdata package (unpatched) is different from that in glibc (see the end of this comment).

(In reply to Carlos O'Donell from comment #28)
> I don't see a clear root cause analysis for why libical fails to load the
> binary time zone data files.

I've a hard time to decipher what libical does and how to fix it. It can be that the QT bug workaround discovered some bug in libical, that's pretty likely, but it's bad in general to apply a workaround for one library and break with it another. Such workaround doesn't fix anything, it only makes things worse. libical 3.0+ has this issue fixed, the problem is with the previous versions only, but libical upstream doesn't seem to invest more time into the 2.0. The last time I tried it looked like the 3.0 change cannot be easily backported. I'll try to search harder.

I'm moving this to libical.

> From a system perspective we want to have just one zic which is used by us
> and our customers for compiling timezone data.

I agree, that makes sense.

Testing a bit further, following the test code from comment #21, the component being returned from libical 3.x (git master for the matter) differs depending whether the tzdata had been compiled with zic with enabled or disabled QT bug workaround. That's maybe expected, but I'm not sure whether in exactly this way. Having disabled the QT bug workaround the example shows component:

   BEGIN:VTIMEZONE
   TZID:/freeassociation.sourceforge.net/Indian/Cocos
   X-LIC-LOCATION:Indian/Cocos
   BEGIN:STANDARD
   TZNAME:+0630
   DTSTART:19700101T000000
   TZO FFSETFROM:+0630
   TZOFFSETTO:+0630
   END:STANDARD
   END:VTIMEZONE

Running the same libical against tzdata generated with zic with enabled QT bug workaround the component is almost the same:

   BEGIN:VTIMEZONE
   TZID:/freeassociation.sourceforge.net/Indian/Cocos
   X-LIC-LOCATION:Indian/Cocos
   BEGIN:STANDARD
   TZNAME:+0630
   DTSTART:20380116T094407
   TZOFFSETFROM:+0630
   TZOFFSETTO:+0630
   RRULE:FREQ=YEARLY;BYDAY=3TU;BYMONTH=1
   END:STANDARD
   END:VTIMEZONE

where the important bits here are the added RRULE and the changed DTSTART. That means that, for latest libical, the QT workaround changes the Indian/Cocos timezone in a way which makes it applicable only after year 2038.

I agree that both components are wrong (the missing RRULE in the first case, and the odd DTSTART at the second case), but I'm not sure what it is supposed to be in reality. I cannot decipher what 'zic' does and why.

Do not understand me wrong, I believe the non-crashing libical is also wrong, just in a different way. I'll commit the change into libical 2.0 for now and extend it if needed/when the additional fix will be known.

libical-2.0.0-13.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-2277aa8b15

libical-2.0.0-13.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-2277aa8b15

libical-2.0.0-13.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.