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