abrt version: 1.1.14 architecture: i686 Attached file: backtrace cmdline: evolution component: evolution crash_function: g_source_destroy_internal executable: /usr/bin/evolution kernel: 2.6.35.10-74.fc14.i686 package: evolution-2.32.1-1.fc14 rating: 4 reason: Process /usr/bin/evolution was killed by signal 11 (SIGSEGV) release: Fedora release 14 (Laughlin) time: 1294755649 uid: 500 How to reproduce ----- 1. Had e-mail open in the background. 2. Crash. 3.
Created attachment 472823 [details] File: backtrace
Thanks for a bug report. The crashing thread doesn't have much with evolution itself, which doesn't mean it's not evolution's fault, as there can be some kind of memory corruption done by evolution causing this crash, but it's not obvious from the backtrace itself. Are there any steps to reproduce this, please? You know, having reproducible steps to the crash is the main key for its fix. Thread 1 (Thread 3695): #0 0x0098dab5 in g_source_destroy_internal (source=0xa24e368, context=0x9e6e208, have_lock=1) at gmain.c:961 #1 0x009911e5 in g_main_dispatch (context=0x9e6e208) at gmain.c:2174 #2 g_main_context_dispatch (context=0x9e6e208) at gmain.c:2702 #3 0x00991978 in g_main_context_iterate (context=0x9e6e208, block=1, dispatch=1, self=<value optimized out>) at gmain.c:2780 #4 0x0099204b in g_main_loop_run (loop=0xa1e0738) at gmain.c:2988 #5 0x075e5499 in IA__gtk_main () at gtkmain.c:1237 #6 0x0804a027 in main (argc=1, argv=0xbfb69ce4) at main.c:679
I would love to provide concise reproducible steps, but there's really none I can give. It really was just open in the background and randomly crashed. I have a feeling it's more related to the Exchange MAPI (evolution-mapi) package plugin than to Evolution itself. I should have mentioned that much originally.
Thanks for the update. Pity it crashes in the background, with not much interaction. I looked into the backtrace again and I see that one thread is synchronizing emails from your exchange server. If it did corrupt the memory, then it's pretty bad. Could you try one thing for me, please? If you can, please run evolution under valgrind, it'll show us something with a bit of luck. As it's awfully slow with it, I would recommend to run it over night (not over the weekend, it's not needed to have it running so long (the log would be too large probably)). I do not know if it's doable for you. In case it is, please run evolution from console like this: $ G_SLICE=always-malloc valgrind --num-callers=50 evolution &>evo.log and the next morning, when it's stopped or you'll close it gracefully, please upload the evo.log file here, to see, whether it faced this or any relevant issue. Thanks in advance.
Created attachment 473539 [details] Requested valgrind w/ evolution
I ran that command; it only seems to run for less than a minute. It didn't spawn an evolution window, so I opened one up alongside it. After a bit it (the valgrind command) quits and that's what is output. I'm unfamiliar with valgrind so I don't know if this is normal or how it's supposed to be used. I tried it a few times and it seems to output similar logs.
If evolution finds any other already running evolution, then it brings it focus and terminates itself, which I believe this one did. Before you invoke the command, please make sure there is no evolution, e-calendar-factory or e-addressbook-factory running. Then the valgrind should run longer.
Created attachment 473918 [details] Valgrind w/ Evolution - 7.5 hours runtime I ran the command for 7.5 hours during while using the Evolution it spawned as I would normally during work operation.
Thanks for an update. valgrind shows nice bunch of invalid reads, unfortunately without detailed traces, as it seems your debug info packages for evolution-data-server, evolution and evolution-mapi are either missing or of an incorrect version (can be caused after update of a base package). Nonetheless, all those are invalid reads, which is not good, but it may not cause memory corruption, only undesired/unexpected behaviour. I do not want to waste your time, because running evolution under valgrind is apart of high CPU usage also awfully slow due to all memory checking. It initially crashed for you when you had evolution in the background, which might mean that this crash is caused by a periodical update in an account (and I hoped also by some memory corruption which seams to be either false or the slowness with valgrind prevented it to exhibit the issue). Could you install/update debug info packages for evolution-data-server, evolution, evolution-mapi and gtkhtml3 and try to find some steps for a reproducer, please? Though to be honest, I do not know with what to start (how to do that). Maybe just use evolution and see whether it'll crash the same way again. I would run evolution like this: $ G_SLICE=always-malloc evolution to give a glib memory checker a bit more chances to spot any issues.
What I'll do is install the debuginfos, then connect via VPN to our mailserver and start Evolution and just let it idle w/Valgrind overnight for a week or so. As mentioned in a different bug, it seems to happen most when it's just there in the background. If it crashes again I'll upload the log. Thanks for looking into this.
Moving to Evolution (was 0xFFFF) -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Backtrace analysis of bugs across components suggests the actual bug is in component gtk2 or glib2 instead of component evolution, reassigning to gtk2. Bugs which were found to be similar to this bug: nautilus: bug #595082, bug #597430, bug #600794 This comment is automatically generated.
This message is a notice that Fedora 14 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 14. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '14' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 14 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping