Evo crashed after resuming from suspend. ABRT pointed me at Bug 1159694, but it doesn't look like the same bug at all. I guess the zero first line confused it. I'm using evolution 3.12.8-1.fc21 and evolution-data-server 3.12.8-2.fc21. #0 0x0000000000000020 in () #1 0x00007f5cbbe35ea2 in g_hash_table_lookup_extended () at /lib64/libglib-2.0.so.0 #2 0x00007f5cc3d324e7 in camel_folder_change_info_add_uid () at /lib64/libcamel-1.2.so.49 #3 0x00007f5c973a6309 in imapx_untagged_fetch () at /usr/lib64/evolution-data-server/camel-providers/libcamelimapx.so #4 0x00007f5c973a7f8c in imapx_untagged () at /usr/lib64/evolution-data-server/camel-providers/libcamelimapx.so #5 0x00007f5c973aee01 in imapx_step () at /usr/lib64/evolution-data-server/camel-providers/libcamelimapx.so #6 0x00007f5c973b022d in imapx_ready_to_read () at /usr/lib64/evolution-data-server/camel-providers/libcamelimapx.so #7 0x00007f5cbbe46aeb in g_main_context_dispatch () at /lib64/libglib-2.0.so.0 #8 0x00007f5cbbe46e88 in g_main_context_iterate.isra () at /lib64/libglib-2.0.so.0 #9 0x00007f5cbbe471b2 in g_main_loop_run () at /lib64/libglib-2.0.so.0 #10 0x00007f5c973a82e6 in imapx_parser_thread () at /usr/lib64/evolution-data-server/camel-providers/libcamelimapx.so #11 0x00007f5cbbe6d7b5 in g_thread_proxy () at /lib64/libglib-2.0.so.0 #12 0x00007f5cc27f952a in start_thread () at /lib64/libpthread.so.0 #13 0x00007f5cbbb4077d in clone () at /lib64/libc.so.6
Created attachment 962400 [details] gdb backtrace Ah, I managed extracting a better backtrace.
Thanks for a bug report. I guess this is related to bug #1073281 and its upstream equivalent. You might find a reproducer, probably. *** This bug has been marked as a duplicate of bug 1073281 ***
Well, what I did is pretty simple: have Evo open for a few hours in the day, close the lid, and open it again in the morning. I'll see whether the crash happens again, but other than that I didn't do anything specific.
I guess you closed the lid when there was an ongoing update of one of your accounts. When you opened it, it was still updating, on a stale connection. Then a network change was recognized, which may disconnect the account and eventually reconnect it, but still with that ongoing update. If you can try to reproduce this with evolution being run under valgrind, then if it's some memory issue (like a use-after-free or similar) then valgrind may catch it. The valgrind command can look like this: $ G_SLICE=always-malloc valgrind --num-callers=20 evolution &>log.txt Only remember to have installed debuginfo packages for at least evolution-data-server and evolution, of the exact same version as their binary packages, thus the log will be usable.