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 737773 - Duplicate GAL in new accounts
Duplicate GAL in new accounts
Status: RESOLVED FIXED
Product: evolution-ews
Classification: Other
Component: Contacts (Global Address List)
3.12.x
Other Linux
: Normal normal
: ---
Assigned To: Evolution EWS maintainer(s)
Evolution EWS maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2014-10-02 09:31 UTC by David Woodhouse
Modified: 2015-02-24 17:04 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description David Woodhouse 2014-10-02 09:31:10 UTC 
When I create a new EWS account, I get *two* instances of 'Global Address List'.

The first one is created thus:

+ Trace 234164

  • #0 camel_ews_settings_set_gal_uid
    at camel-ews-settings.c line 948
  • #1 ews_backend_add_gal_source
    at e-ews-backend.c line 459
  • #2 g_closure_invoke
    at gclosure.c line 768
  • #3 signal_emit_unlocked_R
    at gsignal.c line 3553
  • #4 g_signal_emit_valist
    at gsignal.c line 3309
  • #6 g_object_dispatch_properties_changed
    at gobject.c line 1056
  • #7 g_object_notify_queue_thaw
    at gobject.c line 290
  • #8 g_object_new_internal
    at gobject.c line 1831
  • #9 g_object_new_valist
    at gobject.c line 2034
  • #10 g_object_new
    at gobject.c line 1617
  • #11 e_data_factory_ref_initable_backend
    at e-data-factory.c line 309
  • #12 e_data_factory_ref_backend
    at e-data-factory.c line 230
  • #13 source_registry_server_source_added
    at e-source-registry-server.c line 1180
  • #14 g_closure_invoke
    at gclosure.c line 768
  • #15 signal_emit_unlocked_R
    at gsignal.c line 3591
  • #16 g_signal_emit_valist
    at gsignal.c line 3309
  • #17 g_signal_emit
    at gsignal.c line 3365
  • #18 e_source_registry_server_add_source
    at e-source-registry-server.c line 1562
  • #19 e_source_registry_server_load_file
  • #20 source_registry_server_create_source
    at e-source-registry-server.c line 841
  • #21 source_registry_server_create_sources_cb
    at e-source-registry-server.c line 869
  • #0 camel_ews_settings_set_gal_uid
    at camel-ews-settings.c line 948
  • #1 object_set_property
    at gobject.c line 1415
  • #2 g_object_set_property
    at gobject.c line 2363
  • #3 on_source_notify
    at gbinding.c line 387
  • #4 g_closure_invoke
    at gclosure.c line 768
  • #5 signal_emit_unlocked_R
    at gsignal.c line 3553
  • #6 g_signal_emit_valist
    at gsignal.c line 3309
  • #7 g_signal_emit
    at gsignal.c line 3365
  • #8 g_object_dispatch_properties_changed
    at gobject.c line 1056
  • #9 g_object_notify_queue_thaw
    at gobject.c line 290
  • #10 g_object_thaw_notify
    at gobject.c line 1293
  • #11 source_load_from_key_file
    at e-source.c line 701
  • #12 source_parse_dbus_data
    at e-source.c line 785 


This 1412241251.4654.0@dwoodhou-mobl5.ger.corp.intel.com instance of the GAL stays around, but *not* referenced as 'GalUid' in the account. And soon afterwards, another (..4654.1@...) is created. And this one we *do* remember.

A simple band-aid might be to fix the refcounting so that the unref on the old GAL happens *inside* the camel_ews_settings_set_gal_uid() function. Currently we do that only in ews_backend_source_changed_cb(). But although that might fix the symptoms, we'd still be creating a new GAL only to throw it away again immediately and create a second...
Comment 1 David Woodhouse 2014-10-02 09:33:34 UTC 
Gr, bugzilla is being "helpful" again. That's actually two backtraces, with this sentence in between:

But then the GalUid setting is immediately cleared because we're still parsing the newly-created source, AFAICT:
Comment 2 David Woodhouse 2014-10-02 11:32:16 UTC 
Note that this only happens for newly-created accounts. An account which already existed before this bug will already have a corresponding 'generated' ESource in ~/.cache/evolution/sources/, and *that* will be chosen when we end up in collection_backend_claim_resource() for the resource-id in question. And its UID will also, "coincidentally", be what's set in the gal-uid property right after we set it for ourselves.

I've tested with 3.10 and it doesn't happen there. But I can't see any obvious difference; perhaps something on the EDS side changed the order of initialisation.

This should be fairly easy to reproduce by just 'rm -rf ~/.cache/evolution/sources' and restarting.
Comment 3 Milan Crha 2014-10-10 12:18:20 UTC 
The problem was with notify::online, which is called during object's construct, which "broke" the logic. Postponing the callback registration fixed the issue. I also noticed a problem with not dropped unknown old sources, which is fixed now too (it may remove the second GAL for you). I saw the GAl was constantly rewritten each start of the evolution-source-registry, which is not happening with the below fix.

Created commit 1b498a7 in ews master (3.13.7+) [1]
Created commit 68b89a9 in ews evolution-ews-3-12 (3.12.7+)

[1] https://git.gnome.org/browse/evolution-ews/commit/?id=1b498a7
Comment 4 Milan Crha 2014-10-10 12:39:14 UTC 
Thinking of it...

Created commit db3eb56 in eds master (3.13.7+) [2]
Created commit 12b904c in eds evolution-data-server-3-12 (3.12.7+)

[2] https://git.gnome.org/browse/evolution-data-server/commit/?id=db3eb56
Comment 5 Milan Crha 2015-02-24 16:38:02 UTC 
This seems to be still reproducible with 3.12.10, it seems I didn't cover all cases.
Comment 6 Milan Crha 2015-02-24 17:04:57 UTC 
Ehm, no, there will be opened a new bug report instead, for cases when the server advertises more oflfine books, and one even not being named Global Address List.