Bug 589263 - [PATCH] Google contacts can unlock its cache causing slow updating
[PATCH] Google contacts can unlock its cache causing slow updating
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: evolution-data-server (Show other bugs)
6.0
x86_64 Linux
low Severity medium
: rc
: ---
Assigned To: Matthew Barnes
Desktop QE
abrt_hash:248bdef3d133d89643340d3fa8d...
:
: 589549 (view as bug list)
Depends On:
Blocks: 662543 782183 835616 840699
  Show dependency treegraph
 
Reported: 2010-05-05 13:19 EDT by Ben Woodard
Modified: 2014-01-02 04:05 EST (History)
5 users (show)

See Also:
Fixed In Version: evolution-data-server-2.32.3-3.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-11-20 23:56:44 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
File: backtrace (29.43 KB, text/plain)
2010-05-05 13:19 EDT, Ben Woodard
no flags Details
another backtrace (29.53 KB, application/octet-stream)
2010-05-06 08:31 EDT, Ben Woodard
no flags Details
eds patch (1.00 KB, patch)
2010-11-16 07:16 EST, Milan Crha
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2013:1540 normal SHIPPED_LIVE Low: evolution security, bug fix, and enhancement update 2013-11-20 19:40:51 EST

  None (edit)
Description Ben Woodard 2010-05-05 13:19:31 EDT
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
Comment 1 Ben Woodard 2010-05-05 13:19:32 EDT
Created attachment 411677 [details]
File: backtrace
Comment 3 RHEL Product and Program Management 2010-05-05 14:43:16 EDT
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.
Comment 4 Ben Woodard 2010-05-06 08:28:03 EDT
*** Bug 589549 has been marked as a duplicate of this bug. ***
Comment 5 Ben Woodard 2010-05-06 08:31:06 EDT
Created attachment 411991 [details]
another backtrace
Comment 6 Ben Woodard 2010-05-06 09:05:59 EDT
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.
Comment 7 Matthew Barnes 2010-06-12 16:43:11 EDT
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.
Comment 8 Milan Crha 2010-06-14 05:33:12 EDT
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.
Comment 9 RHEL Product and Program Management 2010-07-15 10:32:07 EDT
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. **
Comment 10 Milan Crha 2010-11-16 07:06:48 EST
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?
Comment 11 Milan Crha 2010-11-16 07:16:25 EST
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.
Comment 13 Ben Woodard 2010-12-01 11:18:37 EST
oops failed to notice the question previously. Sorry. 

It appears to be about 1700.
Comment 14 Ben Woodard 2010-12-01 11:22:33 EST
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.
Comment 15 Milan Crha 2010-12-01 14:55:37 EST
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
Comment 16 Ben Woodard 2010-12-01 15:31:37 EST
I installed the packages. I'll let you know if I see any aborts when trying to compose messages.
Comment 17 Suzanne Yeghiayan 2011-01-05 14:40:10 EST
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.
Comment 18 RHEL Product and Program Management 2011-07-05 20:23:43 EDT
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.
Comment 21 RHEL Product and Program Management 2012-12-14 01:51:22 EST
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.
Comment 23 Milan Crha 2013-05-07 05:06:53 EDT
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?
Comment 24 Ben Woodard 2013-05-07 12:29:24 EDT
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
Comment 26 Milan Crha 2013-05-09 08:26:00 EDT
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).
Comment 35 errata-xmlrpc 2013-11-20 23:56:44 EST
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

Note You need to log in before you can comment on or make changes to this bug.