RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1052772 - [GSS 7.0] address book backend servicing "Red Hat" has quit unexpectedly
Summary: [GSS 7.0] address book backend servicing "Red Hat" has quit unexpectedly
Status: CLOSED DUPLICATE of bug 1131927
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: evolution-data-server
Version: 7.0
Hardware: All
OS: Linux
Target Milestone: rc
: ---
Assignee: Matthew Barnes
QA Contact: Desktop QE
URL: http//
Depends On:
Blocks: 1064025
TreeView+ depends on / blocked
Reported: 2014-01-14 02:55 UTC by Ben Woodard
Modified: 2014-10-08 07:31 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2014-10-08 07:31:05 UTC
Target Upstream Version:

Attachments (Terms of Use)

Description Ben Woodard 2014-01-14 02:55:27 UTC
Description of problem:
periodically evolution's address book quits unexpectedly. I haven't figured out any sequence of events that seems to trigger it. It just seems to happen while I'm composing an email.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
No idea - sorry. It just seems to happen

Additional info:
Configuration straight off of IT's mojo's page.

(evolution:2338): libebook-WARNING **: book_client_view_dispose_cb: The name :1.18 was not provided by any .service files

(evolution:2338): libebook-WARNING **: book_client_view_dispose_cb: The name :1.18 was not provided by any .service files

(evolution:2338): libebook-WARNING **: book_client_view_dispose_cb: The name :1.18 was not provided by any .service files

(evolution:2338): libebook-WARNING **: book_client_view_dispose_cb: No such interface `org.gnome.evolution.dataserver.AddressBookView' on object at path /org/gnome/evolution/dataserver/AddressBookView/2415/25

Comment 2 Milan Crha 2014-01-14 08:01:32 UTC
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, ...

Comment 3 Ben Woodard 2014-01-15 00:40:04 UTC
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

Comment 4 Ben Woodard 2014-01-15 01:07:52 UTC
(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.

Comment 5 Milan Crha 2014-01-15 09:52:29 UTC
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

Comment 6 Ben Woodard 2014-01-15 20:17:40 UTC
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?

Comment 7 Milan Crha 2014-01-16 07:48:04 UTC
(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.

Comment 8 Milan Crha 2014-01-17 18:10:14 UTC
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.

Comment 9 Ben Woodard 2014-01-17 19:44:34 UTC
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.

Comment 10 Milan Crha 2014-01-20 10:17:32 UTC
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.

Comment 11 Milan Crha 2014-01-23 13:51:39 UTC
I'm moving this to evolution-data-server, where the actual crash happened.
I do not have much idea what to try next.

Comment 12 RHEL Program Management 2014-03-22 06:15:01 UTC
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 13 Milan Crha 2014-10-08 07:31:05 UTC
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 ***

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