Hide Forgot
Description of problem: abrt version: 1.1.13 architecture: x86_64 Attached file: backtrace cmdline: evolution --sm-config-prefix /evolution-NrVnKg/ --sm-client-id 108f8bcee7695d03c129168733751575500000021860026 --screen 0 component: evolution crash_function: g_slice_alloc executable: /usr/bin/evolution kernel: 2.6.32-71.18.2.el6.x86_64 rating: 0 reason: Process /usr/bin/evolution was killed by signal 11 (SIGSEGV) time: 1299864913 uid: 500 customer comment --- I have an ongoing problem that I believe may be the source of this difficulty. I have accidently created an aliased inbox. There is the normal Inbox (capital I) and there is a inbox (lower case i) that contains same emails as the normal one. I believe the normal Inbox is an alias pointing to the new inbox. I have been unable to correct this by deleting/renaming. I would like to put the emails, address book, and calendar into an archive, delete all the evolution configuration files, and restore. The backup facility that is provided by evolution restores the two inboxes, and does not fix the problem. I can store the address book as a vCard, and I believe my calendar can be stored as an .ics file (.evolution/calendar/local/system/calendar.ics, is this true?), but I do not know how to export emails in a way that I can recover them. Thanks Version-Release number of selected component (if applicable): Red Hat Enterprise Linux Workstation release 6.0 (Santiago) package: evolution-2.28.3-10.el6 How reproducible: Random crash Steps to Reproduce: 1.received a new email, read it inline (not opening a separate window) 2.clicked on "Reply" in the bar of icons 3.crash Actual results: evolution crahed Expected results: evolution cshould not crashed Additional info:
Created attachment 484160 [details] Backtrace, Dissassembly
Thanks for a bug report. Are you sure this is from evolution, please? The backtrace in comment #2 is from firefox, as far as I can tell. Maybe a typo with an attachment?
Created attachment 485689 [details] Backtrace, Dissassembly
Thanks for the update. It seems to be same as bug #683041 too. It seems you are able to reproduce this, so if I could ask you for a run under valgrind, whether it'll shed some light on the issue, please? It's possible that valgrind will prevent the crash and will just print issues on the console, which is totally fine. You can run valgrind like this: $ G_SLICE=always-malloc valgrind --num-callers=50 evolution &>log.txt and when you repeat the steps then close evolution (if it'll not close itself) and check the log.txt file, whether it contains anything interesting (or simply attach it here). Thanks in advance. Only note that memory checking done by valgrind on evolution code makes it pretty slow.
Since RHEL 6.1 External Beta has begun, and this bug remains unresolved, it has been rejected as it is not proposed as exception or blocker. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux.
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux. If you would like it considered as an exception in the current release, please ask your support representative.
This request was not resolved in time for the current release. Red Hat invites you to ask your support representative to propose this request, if still desired, for consideration in the next release of Red Hat Enterprise Linux.
This request was erroneously removed from consideration in Red Hat Enterprise Linux 6.4, which is currently under development. This request will be evaluated for inclusion in Red Hat Enterprise Linux 6.4.