Version-Release number of selected component: evolution-3.10.0-1.fc20 Additional info: reporter: libreport-2.1.7 backtrace_rating: 4 cmdline: evolution crash_function: slab_allocator_free_chunk executable: /usr/bin/evolution kernel: 3.11.1-300.fc20.x86_64 runlevel: N 5 type: CCpp uid: 1000 Truncated backtrace: Thread no. 1 (10 frames) #0 slab_allocator_free_chunk at gslice.c:1349 #1 magazine_cache_trim at gslice.c:685 #2 magazine_cache_push_magazine at gslice.c:716 #3 thread_memory_magazine2_unload at gslice.c:815 #4 g_slice_free1 at gslice.c:1106 #5 camel_content_type_unref at camel-mime-utils.c:2459 #6 content_info_free at camel-folder-summary.c:3853 #7 camel_folder_summary_content_info_free at camel-folder-summary.c:3294 #8 camel_message_info_free at camel-folder-summary.c:4625 #9 g_slist_foreach at gslist.c:896
Created attachment 804399 [details] File: backtrace
Created attachment 804400 [details] File: cgroup
Created attachment 804401 [details] File: core_backtrace
Created attachment 804402 [details] File: dso_list
Created attachment 804403 [details] File: environ
Created attachment 804404 [details] File: exploitable
Created attachment 804405 [details] File: limits
Created attachment 804406 [details] File: maps
Created attachment 804407 [details] File: open_fds
Created attachment 804408 [details] File: proc_pid_status
Thanks for a bug report. There is filled a similar upstream bug [1], thus I'm moving this there. Please see [1] for any further updates. If possible, please CC yourself there, in case upstream developers will have additional questions. By the way, you seem to be facing broken memory crashes quite often recently (not hardware failures, I rather think of software memory issues, when software writes to a memory which doesn't belong to it anymore, and is occupied by other object). I'm wondering whether you could run evolution under valgrind, which may help to identify some such issues, though the evolution as such will be significantly slower (and more CPU hungry), due to all memory checking. If you could give it a try, to "use" evolution for several hours under valgrind, then maybe it'll show something interesting. The command line is: $ G_SLICE=always-malloc valgrind --num-callers=50 evolution &>log.txt where the final log.txt will contain all found memory issues, if any (valgrind doesn't catch everything, but is good for initial testing). [1] https://bugzilla.gnome.org/show_bug.cgi?id=634285
*** Bug 1014437 has been marked as a duplicate of this bug. ***