To test my assertion that it didn't seem to matter what I did with Evolution when it crashes, I tried one more test where all I did was start Evolution and authenticate with the Exchange server. The application crashed after about 15 minutes--I didn't open any e-mail, contacts, calendars, etc.  Of course, the application did download new e-mail from the Exchange server (and maybe calendar events??), so it did do something when the application started.

Thanks for a bug report. The update itself didn't bring anything directly related, at least on the first look. The crash happens when evolution-ews downloads one of the messages for offline usage. It can be that the message has some structure which confuses evolution-ews, but your log also shows quite many issues with the folder summary (those GError-s). It's not obvious which of the accounts you've configured (it can be the EWS account, but also the On This Computer) has the problem, but if it's the EWS account, then I'd suggest to try to delete the local cache and let it create it from scratch, which means downloading all the messages again. I would get more information from the bactrace, but there are missing debuginfo packages, or at least for evolution-ews, which would show what line it was and in case of the ABRT report also the local variables, which might help. That the crash happens after some time after start possibly depends on the refresh interval you've set for the account. It's in the account properties, Receiving Options tab.

To make evolution-ews re-download the local summary from scratch, do this:
a) close evolution
b) move away: ~/.cache/evolution/mail/<ews-accouint-uid>
   I want to move it away, thus you can eventually return it back, if anything
   goes really wrong
c) run evolution from a terminal, thus you'll see any runtime issues there.

I do not know how the local summary could get broken, but according to the journalctl log it is broken.

Let me know whether it helped, please.

I did as you asked.  Evolution still crashed.  Here are some of the terminal messages (which look a little familiar):


$ evolution

(evolution:4194): camel-CRITICAL **: camel_internet_address_encode_address: assertion 'addr' failed

(evolution:4194): GLib-CRITICAL **: g_string_insert_len: assertion 'len == 0 || val != NULL' failed

(evolution:4194): camel-CRITICAL **: camel_internet_address_encode_address: assertion 'addr' failed

(evolution:4194): GLib-CRITICAL **: g_string_insert_len: assertion 'len == 0 || val != NULL' failed
Segmentation fault (core dumped)



This time Evolution died within just a few minutes of starting as it was synchronizing the folders.

I have created another attachment with the Evolution-specific results from 'journalctl -r' from this experiment.

If I can install some debug libraries, please let me know how I should do it so I can help you determine the source of the problem.

Also, I only have Evolution connected to Exchange right now, so there aren't any other mail accounts used by Evolution.

Created attachment 1419960 [details]
Another 'journalctl -r' for experiment on April 10, 2018

Moved the Exchange data from .cache and started evolution again.  It died after only a few minutes as it was syncing messages from Exchange.

Thanks for the update. Those runtime warnings are new to me. I do not know whether they are related to the crash you are facing or not, but it's possible they are.

To install the debug information packages run as root this:

   # dnf install evolution-data-server-debuginfo evolution-debuginfo \
     evolution-ews-debuginfo --enablerepo=updates-debuginfo

and make sure the versions being downloaded match those you've installed:

   $ rpm -q evolution-data-server evolution evolution-ews

In case you've installed any old debuginfo packages use `dnf update` instead of `dnf install` in the above command.

With that installed, I'd like to see what the server returned too, because it can be something what the evolution-ews doesn't expect. You can do that with the below gdb command, which I'd use to avoid the journalctl usage, because it's not necessary for this testing. Run the command as a regular user, not as root:

   $ EWS_DEBUG=2 gdb evolution --ex r --ex "bt full"

This runs evolution and prints a backtrace when gdb stops. It can stop earlier than on the crash, in which case use gdb command "c" to continue and when it stops again use the gdb command "bt full" to print the backtrace. Then you can either "c" to continue or "q" to quit gdb. The backtrace can contain private information, like server addresses, user emails and such, thus make sure you "censor" them before sharing anywhere. Similarly the exact EWS debugging output contains raw communication between the server and evolution-ews, including content of the messages it downloaded. I'm not interested in the whole EWS log, only some part before the crash happened, and that being "censored" too. I'd like to distinguish between filled and unfilled values though, thus ideally "censor" by replacing letters with an 'x' or such (like from "Milan" making "xxx"). If you'd be unsure or there would be too much to censor, feel free to send it packed to my bugzilla email only, with a reference to this bug report in the subject, thus I'd not overlook it in my spam folder.

I believe you could be able to reproduce the crash when you click the Send/Receive button at the top toolbar, which invokes the message download like with the periodical update. The crash should happen as soon as the refresh (and download for offline usage) reaches the offending message.

I have been able to install the debuginfo packages and run gdb to find the error.  I have sent the sanitized output directly to your bugzilla email.

Thanks!

Thanks, it looks all fine. It seems as evolution-ews failed to parse the iCalendar attachment/part for some reason, but the code expects it always working, thus it crashed short time afterwards. Would it be possible to send me that offending message
   /home/xxx/.cache/evolution/mail/xxx.xxx.x.xxx/folders/
   Deleted Items/mimecontent/JZGDHZ
as an attachment, please? I promise I'll use it only for debugging purposes and will delete it as soon as I'll have it done. I'd like to see whether the iCalendar part is somehow broken or what failed there. It would be particularly easy to just skip all of this in the code, but I'd like to recover as much from the message as possible, similarly like I did recently here:
   https://bugzilla.gnome.org/show_bug.cgi?id=794815
which was about a similar problem (invalid UTF-8 letters in the response from the server caused incomplete calendar content download).

According to the path of the file, the message is in the Deleted Items folder, thus entering it and right-clicking it and pick Refresh may eventually trigger the crash too. I hope you do not have any automatic expunge policy set n the server, because it might purge the message from the Deleted Items when triggered.

I just sent you the uudecoded iCalendar invitation via e-mail.  I had to censor it, but hopefully it is useful.  As I mentioned in the e-mail, I would be happy to run some other tests locally, but I really doubt that it can be cleared for sharing (my apologies).

Created attachment 1422656 [details]
test-rh1565343.c

Thanks for it. I understand the event contains private information, thus it's fine you redacted it. Unfortunately, it seems the decode/censor/something corrected it. I attached a little test program which opens a message you give it a path to (or if you correct the path in the file itself then you can run it without any argument), and it'll try to decode each subpart as iCalendar component and then prints some information about it, including the decoded iCalendar content. The first line of the file contains a comment with a command line to compile it. It requires evolution-data-server-devel and libical-devel packages being installed.
The interesting lines are:
   trying data of len:0 valid utf-8:0 comp:(nil) data:

Thanks for the update (received by email). I've been able to reproduce it too and I realized it had been fixed only recently, here:
https://bugzilla.gnome.org/show_bug.cgi?id=791475#c4
Thus will be part of evolution-data-server 3.28.2+. 

I fixed the crash on the evolution-ews side as well, now that I know it is not an issue on the exchange server, but on the evolution* side instead. Thank you for your help with this.

Created commit f497204 in ews master (3.29.2+) [1]
Created commit 183f9ba in ews gnome-3-28 (3.28.2+)

[1] https://git.gnome.org/browse/evolution-ews/commit/?id=f497204

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

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

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