Bug 1013217

Summary: [abrt] evolution-3.10.0-1.fc20: slab_allocator_free_chunk: Process /usr/bin/evolution was killed by signal 11 (SIGSEGV)
Product: [Fedora] Fedora Reporter: Mikhail <mikhail.v.gavrilov>
Component: evolutionAssignee: Matthew Barnes <mbarnes>
Status: CLOSED UPSTREAM QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 20CC: lucilanga, mbarnes, mcrha
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Whiteboard: abrt_hash:f81a4e168ce80c40c71677f3e11536aa87311b0d
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-09-30 08:40:33 UTC Type: ---
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
File: backtrace
none
File: cgroup
none
File: core_backtrace
none
File: dso_list
none
File: environ
none
File: exploitable
none
File: limits
none
File: maps
none
File: open_fds
none
File: proc_pid_status none

Description Mikhail 2013-09-28 12:10:41 UTC 
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
Comment 1 Mikhail 2013-09-28 12:10:47 UTC 
Created attachment 804399 [details]
File: backtrace
Comment 2 Mikhail 2013-09-28 12:10:50 UTC 
Created attachment 804400 [details]
File: cgroup
Comment 3 Mikhail 2013-09-28 12:10:54 UTC 
Created attachment 804401 [details]
File: core_backtrace
Comment 4 Mikhail 2013-09-28 12:10:58 UTC 
Created attachment 804402 [details]
File: dso_list
Comment 5 Mikhail 2013-09-28 12:11:01 UTC 
Created attachment 804403 [details]
File: environ
Comment 6 Mikhail 2013-09-28 12:11:05 UTC 
Created attachment 804404 [details]
File: exploitable
Comment 7 Mikhail 2013-09-28 12:11:09 UTC 
Created attachment 804405 [details]
File: limits
Comment 8 Mikhail 2013-09-28 12:11:13 UTC 
Created attachment 804406 [details]
File: maps
Comment 9 Mikhail 2013-09-28 12:11:16 UTC 
Created attachment 804407 [details]
File: open_fds
Comment 10 Mikhail 2013-09-28 12:11:20 UTC 
Created attachment 804408 [details]
File: proc_pid_status
Comment 11 Milan Crha 2013-09-30 08:40:33 UTC 
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
Comment 12 Milan Crha 2013-10-02 10:08:39 UTC 
*** Bug 1014437 has been marked as a duplicate of this bug. ***