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
Created attachment 813050 [details] File: backtrace
Created attachment 813051 [details] File: cgroup
Created attachment 813052 [details] File: core_backtrace
Created attachment 813053 [details] File: dso_list
Created attachment 813054 [details] File: environ
Created attachment 813055 [details] File: exploitable
Created attachment 813056 [details] File: limits
Created attachment 813057 [details] File: maps
Created attachment 813058 [details] File: proc_pid_status
Created attachment 813059 [details] File: var_log_messages
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.)
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.
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.
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 ***