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 654472 - Crash on async error return over GDBus
Crash on async error return over GDBus
Status: RESOLVED FIXED
Product: evolution-data-server
Classification: Platform
Component: general
3.2.x (obsolete)
Other Linux
: Normal critical
: ---
Assigned To: Evolution Shell Maintainers Team
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2011-07-12 13:10 UTC by sean finney
Modified: 2013-09-14 16:54 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
eds patch (4.71 KB, patch)
2011-07-27 12:49 UTC, Milan Crha
committed Details | Review

Description sean finney 2011-07-12 13:10:47 UTC
In the contacts pain, select New->Contact, add first/last names and an email, and set the destination addressbook to a MAPI folder.  The Create Contact window then proceeds to hang and not accept input.

The following is output by e-addressbook-factory:

    (e-addressbook-factory:5662): GLib-CRITICAL **: g_variant_new_strv: assertion `length == 0 || strv != NULL' failed
    Segmentation fault

Which in turn seems to be an unhandled error earlier on.  The error starts in build_restriction_emails_contains (./src/addressbook/e-book-backend-mapi-contacts.c) which seems to make an assumption that the email field passed in the sexp will be a fully qualified one.  The email entered was indeed fully qualified, but in this sexp it seems to be passed as just "beginswith firstpart" (i.e. no '@domain.tld').  So this guy returns false, and the error seems to be handled locally but is not properly dealt with later on leading to the segfault.

So I think the follownig needs to happen:

 * Determine whether it's valid that the contact creation should result in an email query that doesn't contain the fully qualified email
 * Handle the failure in build_restriction_emails_contains, or alternatively have it not fail (is it necessary to fail?  and if so is it still relevant with the 0.11 restrictions support?)
 * (Ideally, perhaps out of scope) evo should not hang when the addressbook factory goes away.
Comment 1 sean finney 2011-07-12 13:12:49 UTC
This also affects the "automatically add contacts to Contacts List" feature
Comment 2 Akhil Laddha 2011-07-13 04:55:25 UTC
Crash is critical.
Comment 3 Milan Crha 2011-07-27 12:45:45 UTC
Thanks for a bug report. The crash issue resides in eds, because ema reported an error, but the gdbus template routines for async function I wrote didn't operate properly, thus it crashed. Below is the backtrace for the crash.

(gdb) bt
  • #0 ??
    from /lib64/libglib-2.0.so.0
  • #1 g_variant_builder_add_value
    from /lib64/libglib-2.0.so.0
  • #2 e_gdbus_signal_emission_hook_async_strv
    at e-gdbus-templates.c line 418
  • #3 signal_emission_hook_cb_get_contact_list_done
    at e-gdbus-book.c line 126
  • #4 ??
    from /lib64/libgobject-2.0.so.0
  • #5 g_signal_emit_valist
    from /lib64/libgobject-2.0.so.0
  • #6 g_signal_emit
    from /lib64/libgobject-2.0.so.0
  • #7 e_gdbus_book_emit_get_contact_list_done
    at e-gdbus-book.c line 531
  • #8 e_data_book_respond_get_contact_list
    at e-data-book.c line 880
  • #9 ebbm_operation_cb
    at e-book-backend-mapi.c line 920
  • #10 thread_func_cb
    at em-operation-queue.c line 144
  • #11 ??
    from /lib64/libglib-2.0.so.0
  • #12 ??
    from /lib64/libglib-2.0.so.0
  • #13 start_thread
    from /lib64/libpthread.so.0
  • #14 clone
    from /lib64/libc.so.6

Comment 4 Milan Crha 2011-07-27 12:49:47 UTC
Created attachment 192751 [details] [review]
eds patch

for evolution-data-server;

Use fake values when returning an error from async operation.

I do a change in ema too, to not return the Other Error when it fails to convert query into restrictions. Once when the proper query->restriction convert routine will be done it might be returned back.
Comment 5 Milan Crha 2011-07-27 12:56:56 UTC
Created commit f6ea071 in eds master (3.1.5+)
Created commit 3771ae7 in ema master (3.1.5+)