Thanks for a bug report. From the warnings I guess it's because the evolution-addressbook-factory process crashed at the background. ABRT may catch such crash, if you've it installed, but it's not necessary to install it, just do the following:
a) install debuginfo packages for evolution-data-server, just make sure
   the version will match the binary package version
b) close evolution, if there is left any other evolution-addressbook-factory
   process running, then kill it too
c) run the factory under gdb from a terminal like this:
   $ gdb /usr/libexec/evolution-addressbook-factory --ex "r -w" --ex "t a a bt"
d) finally, run evolution and try to reproduce the crash; there will be one
   difference, instead of crashing, the factory will stop in a gdb prompt,
   possibly printing the backtrace.

I'd like to ask you to provide the backtrace, with few more lines above it (at least from the line like "Program received SIGSEGV" or similar message, after which starts actual backtrace with line numbers and so on.

One important thing, what addressbooks do you have configured? It can be LDAP, On The Web, ...

Here is the backtrace from the coredump. It seems that abrt is picking them up but it is having trouble with the reporting right now and so it didn't submit. It kind of looks like several other ones submitted by abrt. I think you could easily close several as dups. 

Core was generated by `/usr/libexec/evolution-addressbook-factory'.
Program terminated with signal 6, Aborted.
#0  0x00007f948314f979 in __GI_raise (sig=sig@entry=6)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56	  return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
Traceback (most recent call last):
  File "/usr/share/gdb/auto-load/usr/lib64/libgobject-2.0.so.0.3600.3-gdb.py", line 9, in <module>
    from gobject import register
  File "/usr/share/glib-2.0/gdb/gobject.py", line 3, in <module>
    import gdb.backtrace
ImportError: No module named backtrace
...

(gdb) bt
#0  0x00007f948314f979 in __GI_raise (sig=sig@entry=6)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1  0x00007f9483151088 in __GI_abort () at abort.c:90
#2  0x00007f94831900f7 in __libc_message (do_abort=do_abort@entry=2, 
    fmt=fmt@entry=0x7f94832989c8 "*** Error in `%s': %s: 0x%s ***\n")
    at ../sysdeps/unix/sysv/linux/libc_fatal.c:196
#3  0x00007f948319749d in malloc_printerr (ptr=<optimized out>, 
    str=0x7f9483298a38 "double free or corruption (fasttop)", action=3)
    at malloc.c:4972
#4  _int_free (av=0x7f942c000020, p=<optimized out>, have_lock=0)
    at malloc.c:3804
#5  0x00007f948352984f in g_free (mem=0x7f942c002f10) at gmem.c:252
#6  0x00007f9488472cbb in bookview_stop_thread (data=0x7f945c005e60)
    at e-data-book-view.c:266
#7  0x00007f9483548775 in g_thread_proxy (data=0x7f9464003a80) at gthread.c:798
#8  0x00007f94852e3de3 in start_thread (arg=0x7f9449758700)
    at pthread_create.c:308
#9  0x00007f948321025d in clone ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113

(In reply to Milan Crha from comment #2)
> One important thing, what addressbooks do you have configured? It can be
> LDAP, On The Web, ...

oops forgot this. I have RH LDAP configured as specified on the IT mojo page and I have gmail configured.

Hmm, as you use LDAP, then this might be related to [1], but its fix is already included in the evolution-data-server package, thus maybe it's something else. One other backtrace, mentioning the bookview_stop_thread directly, is at [2], but it's still opened, unresolved, and from the file backend (On This Computer/Personal, most likely), which might not be your exact case. I'm still wondering how to reproduce this, it is when the Contacts view, on New Mail Message (Composer), asks the books for autocompletion, but the book is closed too early.

[1] https://bugzilla.gnome.org/show_bug.cgi?id=699448
[2] https://bugzilla.gnome.org/show_bug.cgi?id=706876

Here is a guess as I have racked up more incidents of the problem. Take this with some level of uncertainty.

I think it happens when I'm typing a name with autocompletion going on in the background and I see names pop up which indicate that I've mistyped and then hit backspace some number of times and then continue typing again.

Could it have something to do with thread cancelling in the middle of searches?

(In reply to Ben Woodard from comment #6)
> Could it have something to do with thread cancelling in the middle of
> searches?

Yes, it does have something to do with the cancellation. The method this crashes in is called exactly at the time of the cancel, to indicate that the client is no longer interested in the results of the previously run query. This might be some kind of double-free or use-after-free, it seems to me, like the function is called twice on the same data. That's only a guess. I'll try to reproduce it here shortly.

Hrm, I tried to crash the addressbook factory, but no luck, neither in the message composer when trying ot change the email address quickly, nor when I wrote a simple application to stress-test the book factory by opening and closing different views on a single LDAP book.

How much latency is on your link? I'm sitting out on the end of a reasonably fast link but it does have notable latency. I wonder if that may be the difference.

Maybe the latency does the difference, because, for me, the latency is nothing significant, I write part of the name in message composer and I get suggestions in 2-3 seconds, where part of the delay is caused by the accumulation of responses on the evolution-data-server side. I also run the test with a local addressbook, which is lightning fast.

I'm moving this to evolution-data-server, where the actual crash happened.
I do not have much idea what to try next.

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 believe this is bug #1131927, thus marking it as a duplicate (it has a patch).

*** This bug has been marked as a duplicate of bug 1131927 ***