Description of problem: I didn't pay very good attention this time, if it was exactly as the other times. But at least in 95% of the cases evolution crashed (it crashes quite often, up to now, strangely, more during the morning) when I pressed the button "send/receive". Version-Release number of selected component: evolution-3.8.3-2.fc19 Additional info: reporter: libreport-2.1.5 backtrace_rating: 3 cmdline: evolution executable: /usr/bin/evolution kernel: 3.9.9-302.fc19.i686.PAE runlevel: N 5 uid: 1000 Truncated backtrace: Thread no. 1 (10 frames) #0 ?? #1 g_data_set_internal at gdataset.c:411 #2 g_datalist_id_set_data_full at gdataset.c:674 #3 g_object_notify_queue_thaw at gobject.c:287 #5 g_object_new_valist at gobject.c:1836 #7 g_object_bind_property_full at gbinding.c:936 #8 settings_mail_formatter_constructed at e-settings-mail-formatter.c:121 #10 g_object_new_valist at gobject.c:1836 #12 extensible_load_extension at e-extensible.c:97 #13 e_type_traverse at e-module.c:362
Created attachment 776104 [details] File: backtrace
Created attachment 776105 [details] File: cgroup
Created attachment 776106 [details] File: core_backtrace
Created attachment 776107 [details] File: dso_list
Created attachment 776108 [details] File: environ
Created attachment 776109 [details] File: limits
Created attachment 776110 [details] File: maps
Created attachment 776111 [details] File: open_fds
Created attachment 776112 [details] File: proc_pid_status
Created attachment 776113 [details] File: var_log_messages
Created attachment 776114 [details] File: xsession_errors
Thanks for a bug report. I do not see why exactly the crash is happening, it only shows a memory corruption happened, thus it aborts the application. Could you try to run evolution under valgrind, please? It can show some memory issues. You can do that like this: $ G_SLICE=always-malloc valgrind --num-callers=50 evolution &>log.txt Please, before you run the command, make sure you'll have installed debuginfo packages for at least evolution-data-server and evolution, of the same version as your binary packages. You can verify that with: $ rpm -qa | grep evolution | sort Thanks in advance.
*** Bug 986646 has been marked as a duplicate of this bug. ***
Hello Milan Verifying gives: evolution-3.8.3-2.fc19.i686 evolution-data-server-3.8.3-1.fc19.i686 Personally I don't understand very much, and my technician has decided to force me to learn about :-O, so I have to ask you... I don't know what binary package is... Is evolution and ev. data server the version you want me to have? thank you
(In reply to Cornelia Pfeffer from comment #14) > I don't know what binary package is... I meant with that the package which contains the executable and/or libraries. Those are the two you named above. > Is evolution and ev. data server the version you want me to have? The versions are fine. Please install also debuginfo packages for the named packages, which you can do like this (as root): $ yum install evolution-data-server-debuginfo evolution-debuginfo --enablerepo=updates-debuginfo (it's one long line, not two). The package versions of the installed packages should match package version of the already installed packages. If not, then also run $ yum update evolution-data-server evolution --enablerepo=updates Finally you can install 'valgrind', if not installed yet, and run the command from comment #12. Thanks in advance.
I'm not sure if everything went as it should, nor if I have valgrind or not... nevertheless, I gave all commands you gave me, than I closed evolution, gave the command from comment #12, and after a lot of time, when there seemed to happen nothing, evolution opened. Maybe it is now in the condition it should be... I cleaned the crash- archive, and now let's wait what happens. So, if (or when.... I suppose it will...) evolution crashes again, I will send the bug report, even if the software tells me: the bug is already communicated. Right?
Not having valgrind installed would result in "command not found" error, thus I believe you've it installed, especially if evolution's start took significantly slower, same as its run is significantly slower (it's due to all memory checking done by valgrind). When you'll get to a state where you'll not like the slowness, just close evolution and attach here the resulting log.txt file. The thing is that the valgrind can avoid certain crashes when it detects wrong memory usage, thus the evolution will not crash. but the log.txt can still have the information about incorrectly used memory. It might not contain the issue information for sure, because such memory issues can also depend on "correct" thread interleaving and proper timing, which the all memory checking make significantly harder to reproduce, but let's hope your valgrind session will find something. Thanks a lot for your help with this.
oh yes.. it is so slow, that I'm going mad, having to answer agencys for work... :-) But we also have to find what is happening, so I will try to go on for today.
when I close evolution under valgrind, where will I find the log.txt?
Created attachment 777359 [details] logfile evolution under valgrind
by chance I found it! So now I closed evolution (I really couldn't stand the slowness any more....). It does never crash after opening with Valgrind... so I hope you will see something in the log. Thank you so much
Thanks for the log, I appreciate it. Its content is full of webkit issues (from WTF::fastFree(void*), which might be correct, or not - the last time I checked with a webkit maintainer we didn't find anything obvious why that error is logged by valgrind) and one from html_object_backspace(), at the very end. That comes from a composer, when you deleted some text. There is filled an upstream bug for it [1]. There is not logged anything related to memory corruption, unfortunately, thus I suppose it's about the timing and thread interleaving, which the valgrind slowness changes. > ==17423== LEAK SUMMARY: > ==17423== definitely lost: 3,010,586 bytes in 139,673 blocks > ==17423== indirectly lost: 445,146 bytes in 18,620 blocks > ==17423== possibly lost: 4,461,613 bytes in 30,662 blocks > ==17423== still reachable: 20,709,427 bytes in 341,003 blocks > ==17423== suppressed: 0 bytes in 0 blocks I'm wondering what you did, and from where comes those 3MB of definitely lost memory - these are clear memory leaks identified by valgrind. Nonetheless, I'm currently building 3.8.4 update for evolution packages for Fedora 19, which will be available in updates-testing by the end of this week. I'd say try to update and let's see whether anything will be fixed with it for you. [1] https://bugzilla.gnome.org/show_bug.cgi?id=691342
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is 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 change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. 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.
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.