Description of problem: I just added a new filter rule, and marked all messages in my inbox, then executed "Apply filters" on them. Version-Release number of selected component: evolution-3.20.2-1.fc24 Additional info: reporter: libreport-2.7.1 backtrace_rating: 4 cmdline: evolution crash_function: camel_message_info_ptr executable: /usr/bin/evolution global_pid: 21617 kernel: 4.5.5-300.fc24.x86_64 pkg_fingerprint: 73BD E983 81B4 6521 pkg_vendor: Fedora Project reproducible: Not sure how to reproduce the problem runlevel: N 5 type: CCpp uid: 1000 Truncated backtrace: Thread no. 1 (7 frames) #0 camel_message_info_ptr at camel-folder-summary.c:4620 #1 e_mail_folder_find_duplicate_messages_sync at e-mail-folder-utils.c:796 #2 mail_folder_find_duplicate_messages_thread at e-mail-folder-utils.c:660 #3 run_in_thread at gsimpleasyncresult.c:898 #4 io_job_thread at gioscheduler.c:85 #5 g_task_thread_pool_thread at gtask.c:1288 #7 g_thread_proxy at gthread.c:780
Created attachment 1167089 [details] File: backtrace
Created attachment 1167090 [details] File: cgroup
Created attachment 1167091 [details] File: core_backtrace
Created attachment 1167092 [details] File: dso_list
Created attachment 1167093 [details] File: environ
Created attachment 1167094 [details] File: exploitable
Created attachment 1167095 [details] File: limits
Created attachment 1167096 [details] File: maps
Created attachment 1167097 [details] File: mountinfo
Created attachment 1167098 [details] File: namespaces
Created attachment 1167099 [details] File: open_fds
Created attachment 1167100 [details] File: proc_pid_status
Created attachment 1167101 [details] File: var_log_messages
Thanks for a bug report. It seems to me that you execute "Remove duplicates" on a set of messages, then you executed "Apply filters" on the same set, while this duplicates removal was still processing, when some messages had been moved to a different folder by a filter. The "Remove duplicates" code didn't count with such possibility, which led to the crash. I'm updating the code to verify that the returned message info structure is a valid pointer, not a NULL, like in the case of this crash report. Created commit 44743d4 in evo master (3.21.3+) [1] Created commit a59c0a5 in evo gnome-3-20 (3.20.4+) [1] https://git.gnome.org/browse/evolution/commit/?id=44743d4