Hide Forgot
abrt 1.0.9 detected a crash. architecture: x86_64 Attached file: backtrace cmdline: /usr/libexec/evolution-data-server-2.28 --oaf-activate-iid=OAFIID:GNOME_Evolution_DataServer_InterfaceCheck --oaf-ior-fd=34 component: evolution-data-server executable: /usr/libexec/evolution-data-server-2.28 global_uuid: 248bdef3d133d89643340d3fa8d34b486cb34e61 kernel: 2.6.32-23.el6.x86_64 package: evolution-data-server-2.28.3-3.el6 rating: 4 reason: Process /usr/libexec/evolution-data-server-2.28 was killed by signal 6 (SIGABRT) release: Red Hat Enterprise Linux release 6.0 Beta (Santiago) comment ----- A message like this appeared on the console just before the process started spinning. (evolution:23011): libebook-WARNING **: EBookView: Exception while releasing BookView (evolution:23011): libebook-WARNING **: EBookView: Exception while releasing BookView (evolution:23011): libebook-WARNING **: EBookView: Exception while releasing BookView How to reproduce ----- 1. In this case the data-server was spinning for several minutes and consuming a lot of memory 2. I sent it SIGABRT to get a crash so that we could see why it was spinning. 3. was composing an email and it was trying to autocomplete the email address that I was typing. It seemed to start spinning and evo appeared to freeze. After a few minutes of this I sent it an ABRT
Created attachment 411677 [details] File: backtrace
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux major release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Major release. This request is not yet committed for inclusion.
*** Bug 589549 has been marked as a duplicate of this bug. ***
Created attachment 411991 [details] another backtrace
given a lot of time, whatever is going on might complete. I left it going consuming about 50% CPU for about 15 minutes (wasn't watching exact time >3 min <=15) and it eventually did complete whatever it was doing. However during that time the whole evo UI was locked up.
Conditional NAK -- Steps to reproduce the crash are circumstantial. Need repeatable steps for QA to follow to prove whether the cause of the crash is fixed.
It seems it has some trouble with your Google address book, while updating it. I didn't find corresponding upstream bug, though. I also do not see what may be wrong on the trace, as it says "abort", but I miss there the aborted thread. Could you run evolution-data-server under gdb and attach here its output, as the abrt's is missing console output, please? You can do that by: $ evolution --force-shutdown $ gdb /usr/libexec/evolution-data-server-2.28 --ex r --ex "t a a bt" and then run evolution on another console. When evolution-data-server crashes, it'll print the thread backtrace on the console. Please add here that and couple lines above the crash stop point of the gdb output here. Maybe it'll show us more information. Thanks in advance.
This issue has been proposed when we are only considering blocker issues in the current Red Hat Enterprise Linux release. It has been denied for the current Red Hat Enterprise Linux release. ** If you would still like this issue considered for the current release, ask your support representative to file as a blocker on your behalf. Otherwise ask that it be considered for the next Red Hat Enterprise Linux release. **
Looking into the backtrace it's not quite much obvious how this could happen, only if two book views (like when typing names into To field in the message composer) overlap and one unlocked the cache. Possible steps to reproduce: a) create large enough [1] address book on the Google server b) configure evolution to get contacts from the google address book c) Edit->Preferences->Contacts, check this google address book for autocompletion d) File->New->Mail Message and use few names to complete with this book [1] Ben, how many contacts do you have in yours, please?
Created attachment 460826 [details] eds patch for evolution-data-server; If my previous observation is correct (though I do not have large-enough google addressbook), then this patch may fix the issue. Everything seems fine in the code unless thread interleaving happens. The EFileCache doesn't have freeze counter, only yes/no, thus it cannot be used "recursively". This patch changes yes/no to freeze-counter.
oops failed to notice the question previously. Sorry. It appears to be about 1700.
Hmm, one thing that I've noticed is that it seems to happen most often when I start typing a name and mistype a letter and then hit backspace and fill in the correct letters. Would that create the situation that you describe with overlapping queries? e.g. gromdo^h^h^hndo Can you build me test packages and then I'll give them a run through.
Yes, quickly typing names and correcting them can cause this overlapping. Build with test packages is available here: https://brewweb.devel.redhat.com/taskinfo?taskID=2927997
I installed the packages. I'll let you know if I see any aborts when trying to compose messages.
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. This request has been proposed for 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 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.
I can devel ack this, because there's a patch above, but it'll be better to have also confirmation. Ben, I can build a test package for you. Do you have time and the address book to test it, please?
I'm no longer in a position to test it. I've moved to using F18 and RHEL7a as my primary workstation and my rhel6 installations are rather unconfigured VMs
Thanks for the update, Ben. I see I committed the same change into upstream 2.91.3, but it's not part of 2.32.3, thus no luck with a rebase (bug #883014). If Jirka can test the patch as such, then it'll help (but as it works flawlessly in upstream, we can use it in RHEL6 as well).
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHSA-2013-1540.html