Created attachment 1152913 [details]
File: backtrace

Created attachment 1152914 [details]
File: cgroup

Created attachment 1152915 [details]
File: core_backtrace

Created attachment 1152916 [details]
File: dso_list

Created attachment 1152917 [details]
File: environ

Created attachment 1152918 [details]
File: exploitable

Created attachment 1152919 [details]
File: limits

Created attachment 1152920 [details]
File: maps

Created attachment 1152921 [details]
File: mountinfo

Created attachment 1152922 [details]
File: namespaces

Created attachment 1152923 [details]
File: open_fds

Created attachment 1152924 [details]
File: proc_pid_status

Created attachment 1152925 [details]
File: var_log_messages

Thanks for a bug report. I added a reference to this bug report to a related upstream bug [1].

You wrote above that this problem occurs regularly. When you say regularly, does it mean that you know how to reproduce this, please? What I see from the backtrace is that there crashed an evolution-ews calendar, due to some recurring event. Thus it can be happening only when you select a particular day or anything like that. I think it highly depends on the current content of the EWS calendar, that some interleaving of the events there cause the issue.

What I also see in the backtrace is that the time range which had been checked for events was between Mon Feb 29 11:36:00 UTC 2016 and Mon Apr 11 11:36:00 UTC 2016. Looks like a Month view in the Calendar view of the Evolution?

Please, look at
   ~/.cache/evolution/calendar/
and backup all folders there, except of the 'trash' folder. The evolution-ews calendar(s) stores its local copy there, thus maybe if you can reproduce the crash also without the connection to the internet, then there might be a chance that it will be reproducible also here.

That's the next plea from my side, if you find some steps to reproduce this, could you share with me the content of ~/.cache/evolution/calendar/, thus I'd be able to try to reproduce it here? I would not share it through the bugzilla, because the files there contain your private events and meetings, containing email addresses of the organizer and attendees, names, locations and such among other things, which would be very hard to anonymize, thus, if you'd let me try to reproduce it locally, better to send it directly to my bugzilla email with a reference to this bug report in the Subject (thus I'd not overlook it in my spam folder). I confess I'd use the data only for the testing purposes and will delete then as soon as possible, without sharing with anyone else. You would even encrypt the email with my GPG key [2], for privacy reasons. Feel free to reject the data share, of course.

[1] https://bugzilla.gnome.org/show_bug.cgi?id=634294
[2] https://pgp.mit.edu/pks/lookup?op=get&search=0xFB183E7EF3C36A0D

Hi Milan,

Here are more details about the issue:

The segfaults happen even without evolution running. It appears that gnome-shell (most likely the calendar widget) causes the evolution-calendar-factory to get spawned. While retrieving calendar information the evolution-calendar-factory-subprocess frequently segfaults and gets auto-respawned a couple of seconds later.

This pattern repeats itself for a large number of times, but eventually the segfaults stop and evolution-calendar-factory-subprocess keeps on running normally. Today alone there have already been 439 individual segfaults of the evolution-calendar-factory-subprocess which all happened between 09:17:55 (the moment I logged in to my desktop) and 10:17:56. It is very odd that this is exactly one hour, but could also be coincidence. The evolution-calendar-factory-subprocess which is currently running is still the one which was spawned at 10:17:56.

Both the gnome-shell calendar widget as the calendar inside evolution currently show no events at all.

Yesterday I tried manually purging the contents of the folder ~/.cache/evolution/calendar to force a resync but this didn't help to prevent the segfaults.

The folder ~/.cache/evolution/calendar is regenerated automatically and currently is 397,1MB in size which is a bit too large to distribute over mail. An .tar.xz compressed version of this folder is still 15,8MB which is also too large to send for most mail servers.

I tried to manually debug the issue. Once I managed to catch the segfault with gdb I used lsof to find out which files where currently opened by the evolution-calendar-factory-subprocess and apparently the process only had 1 open file descriptor to a file in the ~/.cache/evolution/calendar folder at the time of the segfault. I don't know if this file was also being used by the segfaulted thread or an unrelated thread, but if you're interested in this file I can send it to you.

I've also just joined IRC (nick: epienbroek) so feel free to ping me when you've got time to continue research on this issue.

This is a follow up from our conversation and live debugging on the IRC. Thanks a lot for it. I made a test build of libical:
http://koji.fedoraproject.org/koji/taskinfo?taskID=13906420

It contains a debugging patch which prints when an icaltimezone is freed (when the icaltimezone_free() function is called). It prints the address of the 'zone' and whether also the structure was requested to be freed. The address can be compared with the one in the crashing thread, it'll be the 'zone'. This print is shown on the evolution-calendar-factory-subprocess console, thus the same as evolution-calendar-factory was run. It depends how often the icaltimezone_free() will be called for you, but catching "the right call" with gdb and get a backtrace where it was freed will be a valuable information, as it might also show why it was freed. Supposing it was freed and not overwritten erroneously from some other place.

Created attachment 1153536 [details]
Valgrind output with libical debug package

Here's the output of valgrind with the debug version of libical installed

Thanks. Here's an update libical build:
http://koji.fedoraproject.org/koji/taskinfo?taskID=13907601

It shows what actual timezone was freed (its TZID and location) and has turned off optimizations, which would make debugging easier. Could you catch the crash in a gdb and also capture the output on the console, then checkout whether the used 'zone' (like in the call to icaltimezone_load_builtin_timezone()) was freed beforehand, please? Knowing the backtrace of the free would be very helpful, but seeing how many times the icaltimezone_free() was called I think it's too complicated to get it. Let's meet on IRC another day and we can discuss options. Maybe I can add there a "system("gdb ....")" call to catch the backtraces, which will make it awfully slow, but I hope useful.

I missed this bug reference when closing the upstream bug report. I'm sorry for that.

I can confirm that the two patches which were added in the upstream bug report resolve the segfault for me:

https://git.gnome.org/browse/evolution-data-server/commit/?id=3ada780
https://git.gnome.org/browse/evolution-ews/commit/?id=2c2a231

*** Bug 1352129 has been marked as a duplicate of this bug. ***

evolution-mapi-3.20.4-1.fc24 evolution-ews-3.20.4-1.fc24 evolution-3.20.4-1.fc24 evolution-data-server-3.20.4-1.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-f9160cfa26

evolution-3.20.4-1.fc24, evolution-data-server-3.20.4-1.fc24, evolution-ews-3.20.4-1.fc24, evolution-mapi-3.20.4-1.fc24 has been pushed to the Fedora 24 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-2016-f9160cfa26

Similar problem has been detected:

Added an appointment to my Exchange 2010 calendar. Then let it sit for a few minutes, then it crashed.

reporter:       libreport-2.7.1
backtrace_rating: 4
cmdline:        /usr/libexec/evolution-calendar-factory-subprocess --factory ews --bus-name org.gnome.evolution.dataserver.Subprocess.Backend.Calendarx1984x4 --own-path /org/gnome/evolution/dataserver/Subprocess/Backend/Calendar/1984/4
crash_function: icaltimezone_load_builtin_timezone
executable:     /usr/libexec/evolution-calendar-factory-subprocess
global_pid:     2180
kernel:         4.6.3-300.fc24.x86_64+debug
package:        evolution-data-server-3.20.3-1.fc24
pkg_fingerprint: 73BD E983 81B4 6521
pkg_vendor:     Fedora Project
reason:         evolution-calendar-factory-subprocess killed by SIGSEGV
reproducible:   Not sure how to reproduce the problem
runlevel:       N 5
type:           CCpp
uid:            1855001104

evolution-3.20.4-1.fc24, evolution-data-server-3.20.4-1.fc24, evolution-ews-3.20.4-1.fc24, evolution-mapi-3.20.4-1.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.