Created attachment 1319126 [details]
File: backtrace

Created attachment 1319127 [details]
File: cgroup

Created attachment 1319128 [details]
File: core_backtrace

Created attachment 1319129 [details]
File: cpuinfo

Created attachment 1319130 [details]
File: dso_list

Created attachment 1319131 [details]
File: environ

Created attachment 1319132 [details]
File: exploitable

Created attachment 1319133 [details]
File: limits

Created attachment 1319134 [details]
File: maps

Created attachment 1319135 [details]
File: open_fds

Created attachment 1319136 [details]
File: proc_pid_status

Created attachment 1319137 [details]
File: var_log_messages

Thanks for a bug report. That reply seems to be just a coincidence to me, but maybe it helps to trigger the issue. At least from the backtrace, you seem to have configured at least two search folders, where one shows flagged messages and one unread. Did you have opened two separate mail windows as well? I understand from the backtrace that one folder got updated, like it changed on the server or some local changes had been saved to the server, which could also mean that deleted messages had been moved to Deleted Items folder and just messages into Junk folder on the server. That would (partly) explain those runtime warnings in var_log_messages attachment. I think of two mail windows, because there are two ongoing operations which fill the message list. It can even be a message opened in a separate window (like when you double-click it in the message list). Those two do not seem to overlap with data.

Also, did you reply in one of those search folders, or in a real folder? I tried to reproduce it here with a single window and single real folder and the reply didn't trigger any issue here.

From another user experiencing the same crash:
a) have turned off preview panel in one folder
b) have IMAP account with "cache message for offline" for this folder
c) have an IMAP folder where server adds a new message, which evolution
   discovers and starts downloading for offline in this folder
d) at the same time, double-click the message to see its content in the new
   message window

It causes the crash there. With some more info about the variables in question:
     message_list_free_value ((ETreeModel *) sort_data->message_list,
      scol->col->spec->compare_col,
      g_ptr_array_index (data->values, ii));
when dereferencing scol->col->spec, 'spec' appears to be garbage
(in free_message_info_data() of course).

Using valgrind or libasan didn't show anything useful.

In my case, the only sort column I have for this folder is "Received".  At some point while sorting messages in ml_sort_uids_by_tree(), the ETableCol object in sort_data.sort_columns gets disposed while the qsort is happening, leading to the crash.

The callstack of what disposes the sort ETableCol is:
etc_dispose()
eth_do_remove()
eth_finalize()
g_object_unref()
tree_table_adapter_dispose()
eti_remove_table_model()
eti_dispose()
g_object_run_dispose()
gnome_canvas_group_dispose()
gnome_canvas_item_dispose()
gnome_canvas_dispose()
g_object_run_dispose()
et_dispose()
g_object_run_dispose()
mail_browser_dispose()
g_object_run_dispose()
close_on_idle_cb()

which is presumably being called by mail_browser_message_list_built_cb() from an idle handler, which itself is called in response to the "message-list-built" signal from message-list.c.

The SEGV stack is:

free_message_info_data()
g_hash_table_foreach()
ml_sort_uids_by_tree()
message_list_regen_thread()
<now in a new thread>
g_simple_async_result_run_in_thread()
message_list_regen_thread()
<spawns an idle handler to run ^^^>
mail_regen_list()

If I "g_object_ref(data->col)" when building up sort_data.sort_columns in ml_sort_uids_by_tree(), and then g_object_unref() those ETableCols at the end of ml_sort_uids_by_tree(), I don't get a crash anymore.

But the message display window doesn't show until whatever background operation is happening completes; you can see it pop up briefly and then it disappears immediately.  If I wait 15 or 30 seconds, then the message window shows up.

This is as far as I have time to go into it.  But seems like the threaded message list regen/sorting stuff is trying to use info that the main thread is disposing.

Alternatively, in ml_sort_uids_by_tree() doing a g_object_ref/g_object_unref on 'adapter' also prevents the crash.

But as with refing the columns themselves, when ref-ing 'adapter' the message view window shows and immediately closes until the folder has actually updated with new messages.  But at least it doesn't crash.

Thanks for the update, that's a very good clue. I can reproduce the crash when I close the message window before it's populated.

This:

> But the message display window doesn't show until whatever background
> operation is happening completes; you can see it pop up briefly and then
> it disappears immediately.  If I wait 15 or 30 seconds, then the message
> window shows up.

is unrelated to the crash, feel free to file a GNOME bug for it, though if I understand the cause, then it'll not be that easy to fix (the folder is most likely locked, due to receiving changes in it, and it cannot do certain operations while locked, thus the code is waiting until the changes are stored/received).

Refing the 'adapter' is not correct, it produces runtime warnings on the console here, about unknown gsignal handler id-s. Reffing columns or anything related to them in the function which is called in a dedicated thread can also lead to a race condition, thus I chose to reference the sort-related members in the main thread and unref them once the message list regeneration is over, which works fine for me.

Created commit c9d48f4a4b in evo master (3.27.90+) [1]
Created commit f94b7a14fc in evo gnome-3-26 (3.26.5+)

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