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 677166 - Salut personas survive disconnection
Salut personas survive disconnection
Product: folks
Classification: Platform
Component: general
git master
Other Linux
: Normal major
: Unset
Assigned To: folks-maint
Depends on:
Reported: 2012-05-31 08:23 UTC by Guillaume Desmottes
Modified: 2012-06-18 11:48 UTC
See Also:
GNOME target: ---
GNOME version: ---

Ensure persona stores are removed when disabled (6.21 KB, patch)
2012-06-18 10:12 UTC, Philip Withnall
committed Details | Review

Description Guillaume Desmottes 2012-05-31 08:23:02 UTC
This is with HEAD of Folks 0.6. (feede0321632b664a981d3df223d7a3724242f5b)

- Make sure to have Salut account configured but disabled
- Start folks-inspect
- persona-stores /org/freedesktop/Telepathy/Account/salut/local_xmpp/account0  (assuming that's the id of your salut Account
- No persona is listed as expected
- Connect the Salut account
- persona-stores /org/freedesktop/Telepathy/Account/salut/local_xmpp/account0
- Some personas are listed (at least your own)
- Disconnect the Salut account
- persona-stores /org/freedesktop/Telepathy/Account/salut/local_xmpp/account0
- Those personas are still listed !

Furthermore, a Warning is raised

(lt-folks-inspect:9586): GLib-CRITICAL **: g_strv_length: assertion `str_array != NULL' failed

(gdb) bt full
  • #0 g_logv
    at gmessages.c line 758
  • #1 g_log
    at gmessages.c line 792
  • #2 g_return_if_fail_warning
    at gmessages.c line 801
  • #3 g_strv_length
    at gstrfuncs.c line 2799
  • #4 folks_inspect_utils_transform_string_array_to_string
    at utils.c line 277
  • #5 _folks_inspect_utils_transform_string_array_to_string_gvalue_transform
    at utils.c line 170
  • #6 g_value_transform
    at gvalue.c line 549
  • #7 folks_inspect_utils_transform_value_to_string
    at utils.c line 1661
  • #8 folks_inspect_utils_property_to_string
    at utils.c line 1640
  • #9 folks_inspect_utils_print_persona
    at utils.c line 617
  • #10 folks_inspect_utils_print_persona_store
    at utils.c line 806
  • #11 folks_inspect_commands_persona_stores_real_run
    at command-persona-stores.c line 309
  • #12 folks_inspect_command_run
    at inspect.c line 1422
  • #13 __lambda5_
    at inspect.c line 1009
  • #14 ___lambda5__rl_vcpfunc_t
    at inspect.c line 1027
  • #15 rl_callback_read_char
    from /lib64/
  • #16 __lambda3_
    at inspect.c line 889
  • #17 ___lambda3__gio_func
    at inspect.c line 899
  • #18 g_io_unix_dispatch
    at giounix.c line 166
  • #19 g_main_dispatch
    at gmain.c line 2539
  • #20 g_main_context_dispatch
    at gmain.c line 3075
  • #21 g_main_context_iterate
    at gmain.c line 3146
  • #22 g_main_loop_run
    at gmain.c line 3340
  • #23 folks_inspect_client_run_interactive
    at inspect.c line 1052
  • #24 folks_inspect_client_main
    at inspect.c line 440
        _tmp7_ = 0x7fffffffd9e8
        _tmp7__length1 = 1
        _inner_error_ = 0x0
        __PRETTY_FUNCTION__ = "folks_inspect_client_main"
Comment 1 Xavier Claessens 2012-05-31 08:26:19 UTC
I have the same with facebook account: when I disable it, the contacts stay.

We should verify if that happens with master as well.
Comment 2 Guillaume Desmottes 2012-05-31 08:32:33 UTC
(In reply to comment #0)
> This is with HEAD of Folks 0.6. (feede0321632b664a981d3df223d7a3724242f5b)

I can reproduce with master as well (03c364f16e9f63967421d8ed526dccf8a26caf13)
Comment 3 Philip Withnall 2012-06-18 09:12:11 UTC
This is because the PersonaStore isn’t being removed when its TpAccount is disabled. The code which should be doing that is here:

but it isn’t being triggered because at that point, the TpAccount is somehow still enabled and valid. Only later does the TpAccountManager emit account-disabled.

I recall being fairly sure that the comment I made when writing that code was correct (i.e. that TpAccount should be set to disabled before the TpConnection is disconnected). Is this not true, or is it a bug in a CM?
Comment 4 Xavier Claessens 2012-06-18 09:19:30 UTC
(In reply to comment #3)
> I recall being fairly sure that the comment I made when writing that code was
> correct (i.e. that TpAccount should be set to disabled before the TpConnection
> is disconnected). Is this not true, or is it a bug in a CM?

I don't think the spec makes that mandatory, so it could even be racy. I would suggest to not depend on event order between Connection and Account since they are from different processes.
Comment 5 Philip Withnall 2012-06-18 09:34:54 UTC
(In reply to comment #0)
> Furthermore, a Warning is raised

That was a separate issue, which I’ve just fixed:

commit 0e729d7be7f3431922aa531704aad897c0bb598b
Author: Philip Withnall <>
Date:   Mon Jun 18 10:31:54 2012 +0100

    telepathy: Set some missing properties on cached TpfPersonas
    Recently-added properties needed implementing for cached personas.

 backends/telepathy/lib/tpf-persona.vala |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)
Comment 6 Philip Withnall 2012-06-18 10:12:42 UTC
Created attachment 216663 [details] [review]
Ensure persona stores are removed when disabled

This should fix it.
Comment 7 Xavier Claessens 2012-06-18 10:28:04 UTC
Comment 8 Guillaume Desmottes 2012-06-18 11:19:55 UTC
Sounds like a good candidate for the stable branch as well.
Comment 9 Philip Withnall 2012-06-18 11:47:46 UTC
Committed to master. I'll backport it to folks-0-6 if we ever make another 0.6 release.

commit 1446c3ed1adafbb153925b81e42e3f199cc1e63a
Author: Philip Withnall <>
Date:   Mon Jun 18 11:08:59 2012 +0100

    telepathy: Don’t create PersonaStores for disabled accounts
    We shouldn’t create persona stores for disabled accounts, as they just sit
    there looking lonely and empty. Persona stores should be created for enabled
    and valid accounts, and should be removed when those accounts are disabled
    or become invalid.

 backends/telepathy/tp-backend.vala |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

commit c8fa98d3ae271c56d7e760f9c2eed37585108541
Author: Philip Withnall <>
Date:   Mon Jun 18 11:04:57 2012 +0100

    Bug 677166 — Salut personas survive disconnection
    Handle TpAccounts being disabled by listening for
    TpAccountManager::account-disabled rather than (erroneously) assuming that
    TpAccount:enabled will have been changed by the time the corresponding
    TpConnection is disconnected.
    This fixes a race condition when accounts are disabled, where the account’s
    personas would persist if TpAccount:enabled hadn’t changed by the time the
    connection was disconnected.
    This comes at the cost of potentially storing and re-loading the set of
    personas for that account to the cache, only to later delete the cache file
    when TpAccount:enabled changes. I can’t think of a simple fix for this.

 NEWS                                          |    3 +-
 backends/telepathy/lib/tpf-persona-store.vala |   50 ++++++++++++++----------
 2 files changed, 31 insertions(+), 22 deletions(-)