Bug 1168832

Summary: Crash when resuming from suspend
Product: [Fedora] Fedora Reporter: Milan Bouchet-Valat <nalimilan>
Component: evolutionAssignee: Milan Crha <mcrha>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 21CC: lucilanga, mbarnes, mcrha, tpopela
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-11-28 09:39:34 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
gdb backtrace none

Description Milan Bouchet-Valat 2014-11-28 07:51:26 UTC 
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
Comment 1 Milan Bouchet-Valat 2014-11-28 08:35:07 UTC 
Created attachment 962400 [details]
gdb backtrace

Ah, I managed extracting a better backtrace.
Comment 2 Milan Crha 2014-11-28 09:39:34 UTC 
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 ***
Comment 3 Milan Bouchet-Valat 2014-11-28 09:44:40 UTC 
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.
Comment 4 Milan Crha 2014-11-28 10:28:12 UTC 
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.