Bug 1019944

Summary: [abrt] evolution-3.10.0-1.fc20: magazine_chain_pop_head: Process /usr/bin/evolution was killed by signal 11 (SIGSEGV)
Product: [Fedora] Fedora Reporter: ringwald
Component: evolutionAssignee: Matthew Barnes <mbarnes>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 20CC: lucilanga, mbarnes, mcrha, ringwald
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Whiteboard: abrt_hash:a08c1fe02e5ad7a51ede6e0fa9752598b28e1e22
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-10-17 07:20:21 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: proc_pid_status
none
File: var_log_messages none

Description ringwald 2013-10-16 16:37:47 UTC 
Version-Release number of selected component:
evolution-3.10.0-1.fc20

Additional info:
reporter:       libreport-2.1.8
backtrace_rating: 4
cmdline:        evolution
crash_function: magazine_chain_pop_head
executable:     /usr/bin/evolution
kernel:         3.11.5-300.fc20.x86_64
open_fds:       
runlevel:       N 5
type:           CCpp
uid:            1000

Truncated backtrace:
Thread no. 1 (6 frames)
 #0 magazine_chain_pop_head at gslice.c:541
 #1 magazine_chain_prepare_fields at gslice.c:623
 #2 magazine_cache_push_magazine at gslice.c:697
 #3 private_thread_memory_cleanup at gslice.c:783
 #4 __nptl_deallocate_tsd at pthread_create.c:157
 #6 clone at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Potential duplicate: bug 733919
Comment 1 ringwald 2013-10-16 16:37:50 UTC 
Created attachment 813050 [details]
File: backtrace
Comment 2 ringwald 2013-10-16 16:37:53 UTC 
Created attachment 813051 [details]
File: cgroup
Comment 3 ringwald 2013-10-16 16:37:56 UTC 
Created attachment 813052 [details]
File: core_backtrace
Comment 4 ringwald 2013-10-16 16:37:58 UTC 
Created attachment 813053 [details]
File: dso_list
Comment 5 ringwald 2013-10-16 16:38:01 UTC 
Created attachment 813054 [details]
File: environ
Comment 6 ringwald 2013-10-16 16:38:04 UTC 
Created attachment 813055 [details]
File: exploitable
Comment 7 ringwald 2013-10-16 16:38:06 UTC 
Created attachment 813056 [details]
File: limits
Comment 8 ringwald 2013-10-16 16:38:10 UTC 
Created attachment 813057 [details]
File: maps
Comment 9 ringwald 2013-10-16 16:38:13 UTC 
Created attachment 813058 [details]
File: proc_pid_status
Comment 10 ringwald 2013-10-16 16:38:15 UTC 
Created attachment 813059 [details]
File: var_log_messages
Comment 11 Milan Crha 2013-10-16 17:04:48 UTC 
Thanks for a bug report. It seems to me that the evolution crashed due to some (software) memory corruption. Do you know what you've (or evolution) been doing before the crash, please? It's quite hard to spot such kind of issues without clues. (Maybe it's related to bug #1018870.)
Comment 12 ringwald 2013-10-16 18:06:46 UTC 
I installed Fedora 20. Rebooted the machine and logged in. Started Evolution, and put in my account information. I clicked on Inbox, and it crashed.
Comment 13 ringwald 2013-10-16 18:09:30 UTC 
I thought that it might have something to do with a memory error as well, as the trace looked suspicious. Even though I have ECC RAM in my workstation, I ran memTest86 on the system, with no issues reported.
Comment 14 Milan Crha 2013-10-17 07:20:21 UTC 
I do not think it's a hardware memory issue, by (software) memory corruption is meant a problem in an application accessing already freed or uninitialized memory, which can cause basically anything, and be found (by a crash or other means) any time later, not necessarily immediately when it happens.

I see your other bug #1019996 is about (software) memory corruption too, which might be the same reason like here. Let's mark this as a duplicate of it.

By the way, if it's that easy to reproduce for you, could you install valgrind, and debug info packages for evolution-data-server and evolution, and run evolution under valgrind, to see whether it'll spot where the memory corruption happened? Valgrind can catch certain memory issues. The command would be:
   $ G_SLICE=always-malloc valgrind --num-callers=50 evolution &>log.txt
and then just try to work as before. Note, the evolution will be significantly slower, due to all memory checking (it'll also have high CPU usage). Even if evolution will not crash this time, the log.txt file can contain information about the memory issue. There is also a possibility that the error will not happen under valgrind, especially if it depends on "proper" timing, thread interleaving and such. It's hard to guess, but I believe it worth a try. Please update either this or the other bug when/if you've something. Thanks in advance.

*** This bug has been marked as a duplicate of bug 1019996 ***