|Summary:||[GSS 7.0] address book backend servicing "Red Hat" has quit unexpectedly|
|Product:||Red Hat Enterprise Linux 7||Reporter:||Ben Woodard <woodard>|
|Component:||evolution-data-server||Assignee:||Matthew Barnes <mbarnes>|
|Status:||CLOSED DUPLICATE||QA Contact:||Desktop QE <desktop-qa-list>|
|Version:||7.0||CC:||fidencio, mcrha, vanhoof, vgaikwad, woodard|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2014-10-08 07:31:05 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:|
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): evolution-3.8.5-11.el7.x86_64 evolution-data-server-3.8.5-10.el7.x86_64 How reproducible: periodic 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 , 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 , 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.  https://bugzilla.gnome.org/show_bug.cgi?id=699448  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.