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 659732 - Gnome fails to load and crashes when the Evolution-exchange plugin is configured
Gnome fails to load and crashes when the Evolution-exchange plugin is configured
Product: folks
Classification: Platform
Component: e-d-s backend
git master
Other Linux
: Normal critical
: folks-0.6.4
Assigned To: folks-maint
Depends on:
Reported: 2011-09-21 15:11 UTC by Milan Crha
Modified: 2011-09-21 23:05 UTC
See Also:
GNOME target: ---
GNOME version: ---

patch (3.57 KB, patch)
2011-09-21 16:42 UTC, Raul Gutierrez Segales
needs-work Details | Review

Description Milan Crha 2011-09-21 15:11:02 UTC
Moving this from a downstream bug report:

After some investigation, folks' eds backend crashes when ESource doesn't have a relative_uri set. The right value to use is ESource's UID, as it's a unique identifier among all ESources - the relative URI can repeat, only user can be different.

The thing is that this crash in folks crashes gnome-shell, thus the session is not runnable.

Core was generated by `/usr/bin/gnome-shell'.
Program terminated with signal 11, Segmentation fault.

Thread 1 (Thread 0xb775c880 (LWP 2007))

  • #0 g_str_hash
    at gstring.c line 142
  • #1 gee_hash_map_lookup_node
    at hashmap.c line 930
  • #2 gee_hash_map_real_has_key
    at hashmap.c line 969
  • #3 gee_abstract_map_has_key
    at abstractmap.c line 313
  • #4 _folks_backends_eds_backend_ab_source_list_changed_cb
    at /opt/gnome2/source/folks/backends/eds/eds-backend.vala line 180
  • #5 g_cclosure_marshal_VOID__VOID
    at gmarshal.c line 85
  • #6 g_closure_invoke
    at gclosure.c line 774
  • #7 signal_emit_unlocked_R
    at gsignal.c line 3272
  • #8 g_signal_emit_valist
    at gsignal.c line 3003
  • #9 g_signal_emit
    at gsignal.c line 3060
  • #10 load_from_gconf
    at e-source-list.c line 172
  • #11 conf_changed_callback
    at e-source-list.c line 234
  • #12 notify_listeners_callback
    at gconf-client.c line 2810
  • #13 notify_listener_list
    at gconf-listeners.c line 590
  • #14 ltable_notify
    at gconf-listeners.c line 656
  • #15 gconf_listeners_notify
    at gconf-listeners.c line 185
  • #16 notify_one_entry
    at gconf-client.c line 2835
  • #17 gconf_client_flush_notifies
    at gconf-client.c line 2875
  • #18 notify_idle_callback
    at gconf-client.c line 2769
  • #19 g_idle_dispatch
    at gmain.c line 4801
  • #20 g_main_dispatch
    at gmain.c line 2441
  • #21 g_main_context_dispatch
    at gmain.c line 3011
  • #22 g_main_context_iterate
    at gmain.c line 3089
  • #23 g_main_loop_run
    at gmain.c line 3297
  • #24 meta_run
    at core/main.c line 555
  • #25 main
    at main.c line 571

Comment 1 Raul Gutierrez Segales 2011-09-21 15:19:49 UTC
Thanks for the report. We were under the false assumption that e_source_peek_relative_uri () was always non NULL (but still, some defensive programming could have been in place). We'll now be switching to e_source_peek_uid ().
Comment 2 Raul Gutierrez Segales 2011-09-21 16:07:33 UTC
On a second thought, this might not be that straight forward. We depend on the relative uri to configure the primary store, among other things (because it's an easy way to map address books). 

I'll investigate the possibility of using the absolute URI, but still this might have other implications.
Comment 3 Raul Gutierrez Segales 2011-09-21 16:42:31 UTC
Created attachment 197173 [details] [review]

This is more a workaround than a proper fix. We should re-think on how we'd like to refer to ESources and decouple the relative URI from the PersonaStore id entirely if possibly (and tie the latter to the ESource's UID).
Comment 4 Philip Withnall 2011-09-21 16:45:43 UTC
Review of attachment 197173 [details] [review]:

Eep, this feels nasty. Why can't we just go with = ESource.peek_uid() everywhere? I think we can get away with it because is defined as an opaque string, so it's not an API break.
Comment 5 Matthew Barnes 2011-09-21 16:46:53 UTC
ESources won't have URLs for much longer, so you'll be more future-proof by limiting how and where you use them.  ESources should be uniquely identified by their UID string, which is permanent.
Comment 6 Raul Gutierrez Segales 2011-09-21 22:12:01 UTC
Here is a new take going for UID and leaving URIs aside:
Comment 7 Raul Gutierrez Segales 2011-09-21 23:05:48 UTC

commit 3b5f532c3975fb96a725f10d6cbf0b03b61f95fb
Author: Raul Gutierrez Segales <>
Date:   Wed Sep 21 23:05:42 2011 +0100

    eds: split up link-personas test and cut relative URI dependency
    Though some code might be duplicated, it's healthy to split tests
    into different executables to assure our clean-up code (wiping out
    GConf entries, shutting down our own session Bus, etc) runs between

commit 0ff740a9026592f723a6b219906a4823f2ec04fa
Author: Raul Gutierrez Segales <>
Date:   Wed Sep 21 22:07:27 2011 +0100

    eds: rework tests so that they don't depend on relative URIs
    Previously, tests were build around the assumption that each
    Edsf.PersonaStore had an id == ESource.relative_uri. That
    stopped being true (because you'll get swallowed by a black
    hole in pwithnall's garden if you use relative URIs).

commit 73647bc63e66c085bf0a1a7080df9734734c77b7
Author: Raul Gutierrez Segales <>
Date:   Wed Sep 21 16:24:30 2011 +0100

    e-d-s: use UID instead of relative URI to track ESources
    Some e-d-s backends (i.e.: the Exchange one) might not have
    a relative URI so we can't rely on it as an address book
    identifier. So from now on we use the ESource's UID.