After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 638821 - Abort in e-addressbook-factory due to freed backend
Abort in e-addressbook-factory due to freed backend
Status: RESOLVED FIXED
Product: evolution-mapi
Classification: Applications
Component: Contacts (Addressbook)
3.0.x
Other Linux
: Normal critical
: ---
Assigned To: evolution-mapi-maint
evolution-mapi-maint
: 655314 655316 655930 655932 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2011-01-06 12:07 UTC by Milan Crha
Modified: 2011-09-23 07:42 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
ema patch (3.94 KB, patch)
2011-08-05 16:59 UTC, Milan Crha
committed Details | Review

Description Milan Crha 2011-01-06 12:07:27 UTC
Moving this from a downstream bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=667110

abrt version: 1.1.14
architecture: x86_64
Attached file: backtrace
cmdline: /usr/libexec/e-addressbook-factory
component: evolution-data-server
crash_function: talloc_abort
executable: /usr/libexec/e-addressbook-factory
kernel: 2.6.35.10-74.fc14.x86_64
package: evolution-data-server-2.32.1-1.fc14
rating: 4
reason: Process /usr/libexec/e-addressbook-factory was killed by signal 6
(SIGABRT)
release: Fedora release 14 (Laughlin)
time: 1294148423
uid: 500

How to reproduce
-----
1. Just sent an email when the crash occurred.

Core was generated by `/usr/libexec/e-addressbook-factory'.
Program terminated with signal 6, Aborted.

Thread 1 (Thread 2695)

  • #0 raise
    from /lib64/libc.so.6
  • #1 abort
    from /lib64/libc.so.6
  • #2 talloc_abort
    at talloc.c line 199
  • #3 talloc_abort_unknown_value
    at talloc.c line 223
  • #4 talloc_chunk_from_ptr
    at talloc.c line 242
  • #5 __talloc
    at talloc.c line 400
  • #6 talloc_named
    at talloc.c line 917
  • #7 Release
    at libmapi/IUnknown.c line 132
  • #8 mapi_object_release
    at libmapi/mapi_object.c line 99
  • #9 Logoff
    at libmapi/IMSProvider.c line 307
  • #10 disconnect
    at exchange-mapi-connection.c line 178
  • #11 exchange_mapi_connection_finalize
    at exchange-mapi-connection.c line 225
  • #12 g_object_unref
    at gobject.c line 2695
  • #13 ebbm_dispose
    at e-book-backend-mapi.c line 1348
  • #14 g_object_unref
    at gobject.c line 2658
  • #15 e_data_book_dispose
    at e-data-book.c line 867
  • #16 g_object_unref
    at gobject.c line 2658
  • #17 impl_Book_close
    at e-data-book.c line 754
  • #18 _e_gdbus_gdbus_cclosure_marshaller_BOOLEAN__OBJECT
    at e-gdbus-marshallers.c line 165
  • #19 g_closure_invoke
    at gclosure.c line 766
  • #20 signal_emit_unlocked_R
    at gsignal.c line 3252
  • #21 g_signal_emit_valist
    at gsignal.c line 2993
  • #22 g_signal_emit
    at gsignal.c line 3040
  • #23 handle_method_call
    at e-gdbus-egdbusbook.c line 3722
  • #24 call_in_idle_cb
    at gdbusconnection.c line 4397
  • #25 g_main_dispatch
    at gmain.c line 2149
  • #26 g_main_context_dispatch
    at gmain.c line 2702
  • #27 g_main_context_iterate
    at gmain.c line 2780
  • #28 g_main_loop_run
    at gmain.c line 2988
  • #29 main
    at e-data-book-factory.c line 619

Comment 1 Milan Crha 2011-06-27 05:55:32 UTC
Same issue from 3.0.2:
https://bugzilla.redhat.com/show_bug.cgi?id=716418
Comment 2 Milan Crha 2011-07-26 10:48:21 UTC
*** Bug 655316 has been marked as a duplicate of this bug. ***
Comment 3 Milan Crha 2011-08-05 16:59:41 UTC
Created attachment 193321 [details] [review]
ema patch

for evolution-mapi;

This, together with a fix from an OpenChange issue [1], fixes the problem for me. My reproducer steps were pretty simple, though it requires OpenChange 0.11 for me:
a) close all evolution-related processes
b) run e-addressbook-factory under valgrind (not because getting it slow, but
   to have show issues, if any)
c) run evolution; make sure at least two books from MAPI are set
   for autocompletion
d) invoke a new message composer and autocomplete there, but do not wait
   too long - for me was enough when the local addressbook returned a result
   for the completion query
e) close composer window

All these steps may result in a backend removal from the factory, thus also for a Logoff() call. The main thing was that the backend gone before it finished its waiting for connection, thus anything later was done on an already freed object.

See [1] for details of an issue on OpenChange 0.11 side.

[1] http://tracker.openchange.org/issues/366
Comment 4 Milan Crha 2011-08-05 17:09:34 UTC
Created commit 84b5100 in ema master (3.1.5+)
Created commit 2b71f90 in ema gnome-3-0 (3.0.3+)
Comment 5 Milan Crha 2011-08-05 17:11:46 UTC
*** Bug 655314 has been marked as a duplicate of this bug. ***
Comment 6 Milan Crha 2011-08-05 17:12:38 UTC
*** Bug 655930 has been marked as a duplicate of this bug. ***
Comment 7 Milan Crha 2011-08-05 17:13:35 UTC
*** Bug 655932 has been marked as a duplicate of this bug. ***
Comment 8 Artur Flinta 2011-09-20 12:31:49 UTC
I'm still having this crash when working with Exchange 2007.

[]$ rpm -qa |grep evolution
evolution-NetworkManager-3.0.3-1.fc15.x86_64
evolution-3.0.3-1.fc15.x86_64
evolution-mapi-3.0.3-2.fc15.x86_64
evolution-data-server-3.0.3-1.fc15.x86_64

Abrt is trying to report this crash as bug 719841.
Comment 9 Milan Crha 2011-09-21 07:39:34 UTC
Hrm, then it might mean either I didn't spot all cases with the fix or the issue is slightly different with openchange 0.9. How do your steps differ from that mine from comment #3, please?
Comment 10 Artur Flinta 2011-09-21 08:09:25 UTC
The most popular crash is when I have two composer windows opened, enter e-mail in first window, then EDS dies immediatelly after autocompletion e-mail address in second composer window.
Comment 11 Milan Crha 2011-09-23 07:27:53 UTC
Hrm, I tried to reproduce this with 3.1.92 and no luck. What I do:
a) open a new composer window A
b) open a new composer window B
c) autocomplete in B a contact from evo-mapi addressbook
d) switch to A and autocomplete the same contact from evo-mapi addressbook
e) close A and B composers (order doesn't matter)

I also see the e-addressbook-factory being correctly closed when no longer needed (after I closed both composer windows)
Comment 12 Artur Flinta 2011-09-23 07:42:36 UTC
Seems, that I have to install virtual F16 alpha, make mass upgrade, and try it. From my local notebook, I have to stick with F15 packages.... as stable ones ;)