Version-Release number of selected component: evolution-3.30.5-1.fc29 Additional info: reporter: libreport-2.10.0 backtrace_rating: 4 cmdline: evolution crash_function: camel_imapx_folder_set_mailbox executable: /usr/bin/evolution journald_cursor: s=2674d763869d47878e4a7da67b711f12;i=728e2a;b=f5cbe819ff4243cc9e75e1aa3e4fcdca;m=921c2e30;t=5822e76ea5956;x=1afaa8f67df316b7 kernel: 4.20.7-200.fc29.x86_64 rootdir: / runlevel: N 5 type: CCpp uid: 1000 Truncated backtrace: Thread no. 1 (6 frames) #0 camel_imapx_folder_set_mailbox at /usr/src/debug/evolution-data-server-3.30.5-1.fc29.x86_64/src/camel/providers/imapx/camel-imapx-folder.c:1368 #1 camel_imapx_folder_list_mailbox at /usr/src/debug/evolution-data-server-3.30.5-1.fc29.x86_64/src/camel/providers/imapx/camel-imapx-folder.c:1464 #2 imapx_synchronize_sync at /usr/src/debug/evolution-data-server-3.30.5-1.fc29.x86_64/src/camel/providers/imapx/camel-imapx-folder.c:843 #3 camel_folder_synchronize_sync at /usr/src/debug/evolution-data-server-3.30.5-1.fc29.x86_64/src/camel/camel-folder.c:3821 #4 session_job_thread at /usr/src/debug/evolution-data-server-3.30.5-1.fc29.x86_64/src/camel/camel-session.c:196 #6 g_thread_proxy at gthread.c:784 Potential duplicate: bug 1317369
Created attachment 1536079 [details] File: cgroup
Created attachment 1536080 [details] File: core_backtrace
Created attachment 1536081 [details] File: cpuinfo
Created attachment 1536082 [details] File: dso_list
Created attachment 1536083 [details] File: environ
Created attachment 1536084 [details] File: exploitable
Created attachment 1536085 [details] File: limits
Created attachment 1536086 [details] File: maps
Created attachment 1536087 [details] File: mountinfo
Created attachment 1536088 [details] File: open_fds
Created attachment 1536089 [details] File: proc_pid_status
Thanks for a bug report. I see from the backtrace that one of your IMAP folders had been updating in one thread, while another thread removed the reference to it, thus the folder object had been freeing while being used elsewhere (in a different thread). It looks like a ref/unref imbalance on the first look. I'll investigate this further and update this bug when I know more.
Thanks, Milan!
After reading the code and checking references, it seems to me that you've been searching in some folder with other that "in Current Folder" option. There's a bug in the code when the search is cleared, but I cannot reproduce the incorrect free of the object (due to unref being called more times than the 'ref'), even the error in the code if obvious, thus it can be that some other part of the code leverage the extra unref by adding an extra ref for some reason. By any chance, do you recall whether you've been searching before the crash (it's most likely multiple times, invoked from single folder). The backtrace also shows in which folder that had been most likely done, search it for "INBOX/" (quotes for clarity only), I do not want to place it here, in case you'd consider the folder name a private information.
I committed a change [1], which fixes few places, which I noticed are doing things wrong with respect of a CamelFolder ref/unref imbalance. It may address this crash as well, but I do not have a reproducer for this crash, thus I cannot tell for sure. Nonetheless I believe this change had its impact on this, because I've been able to reproduce a similar issue on quit of Evolution. I'm closing this in favour of the change [1], which will be released for 3.31.92+, thus for 3.32.0 in Fedora 30. [1] https://gitlab.gnome.org/GNOME/evolution/commit/f804af97fe
(In reply to Milan Crha from comment #15) > > By any chance, do you recall whether you've been searching before the crash > (it's most likely multiple times, invoked from single folder). The backtrace > also shows in which folder that had been most likely done, search it for > "INBOX/" (quotes for clarity only). Yes, indeed, I've been searching before the crash occurred. Thanks for your quick response and the commit that tries to conquer the CamelFolder ref/unref imbalance!