GNOME Bugzilla – Bug 627242
Some contacts stay in the contact list once disconnected
Last modified: 2010-08-27 10:08:06 UTC
When I change my presence to offline most of my contacts disappear from the contacts list as expected but a few stay there (their presence is unchanged). Not sure if it's related but something is going wrong, I have a lot of this kind of warnings: (empathy:25893): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed (empathy:25893): GLib-GObject-WARNING **: instance of invalid non-instantiatable type `(null)' (empathy:25893): GLib-GObject-CRITICAL **: g_signal_handlers_disconnect_matched: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed Unfortunatelly I can't easily get a trace for those because I have a shit load of (empathy:25893): TelepathyBackend-WARNING **: tpf-persona.vala:265: Group invalidated: User requested disconnection warnings before so it crashed before if I use fatal-criticals.
For the record, I send a log of this issue to Travis and Philip by mail.
(In reply to comment #0) > When I change my presence to offline most of my contacts disappear from the > contacts list as expected but a few stay there (their presence is unchanged). I can reproduce this some of the time; sometimes the list is empty as expected. And some of the times I get the warnings below, but can continue along; other times, it ends up in a full-out crash (due to a double-free). Neither of these problems happen when I have zero linked contacts. > Not sure if it's related but something is going wrong, I have a lot of this > kind of warnings: > > (empathy:25893): GLib-GObject-CRITICAL **: g_object_unref: assertion > `G_IS_OBJECT (object)' failed This is due to TpfPersonaStore. When the TpConnection becomes disconnected, we reset some internal state in the TpfPersonaStore. This ends up finalizing a GeeHashMap (which maps TpHandles to TpfPersonas), which frees its keys and values. The problem is that, in the case above, the TpfPersona seems to be disposed early. I suspect there's something in Empathy that's excessively unreffing the persona. Of course, there are so many things that hold references to the personas that this is turning out to be very difficult to debug. But I'm very confident it's in Empathy, not Folks (after combing through the generated C code for Folks very carefully). > (empathy:25893): GLib-GObject-WARNING **: instance of invalid > non-instantiatable type `(null)' > > (empathy:25893): GLib-GObject-CRITICAL **: > g_signal_handlers_disconnect_matched: assertion `G_TYPE_CHECK_INSTANCE > (instance)' failed > > Unfortunatelly I can't easily get a trace for those because I have a shit load > of > (empathy:25893): TelepathyBackend-WARNING **: tpf-persona.vala:265: Group > invalidated: User requested disconnection > warnings before so it crashed before if I use fatal-criticals. These shouldn't show up in Folks >= 0.1.14.1 (though I couldn't reproduce these in the first place).
This double-freeing of Personas may be happening because your linked Individuals contain duplicate Personas, but the duplicates are only duplicate entries (i.e. two list elements referring to the same object instance, so they're effectively sharing a reference). I fixed this here: http://git.collabora.co.uk/?p=user/pwith/folks;a=shortlog;h=refs/heads/626544-im-address-duplicates so you might want to see if that fixes the problem.
I tried your branch and got this error when disconnecting: Lib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed aborting... Program received signal SIGTRAP, Trace/breakpoint trap. 0x00007ffff49436c6 in g_logv (log_domain=0x7ffff4e594cf "GLib-GObject", log_level=G_LOG_LEVEL_CRITICAL, format=0x7ffff49bcb18 "%s: assertion `%s' failed", args1=0x7fffffffd470) at gmessages.c:544 544 G_BREAKPOINT (); (gdb) bt
+ Trace 223328
I've got the same problem as Guillaume as well - that branch doesn't seem to affect this bug (though there could be a related problem in some other code).
(It wasn't meant to; I just thought it might help when I saw this bug.)
Created attachment 168861 [details] [review] Don't filter out removals of re-linked Individual at the IndividualManager This patch is the squashed (though already 1-commit) version of the changes in this branch: http://git.collabora.co.uk/?p=user/treitter/empathy.git;a=shortlog;h=refs/heads/bgo627242 The net effect of this branch is to have the IndividualManager signal the removal of re-linked Individuals who are removed by a Telepathy account going offline. The existing code should have already supported this, except a strange phenomenon prevented it from working properly: IndividualManager->priv->individuals stores a mapping of {Individual id: Individual}. Upon Connection status change to DISCONNECTED, priv->individuals would contain only the second-last-to-be-removed Individual ("Individual X") at the time it was trying to remove the last (re-linked) Individual ("Individual Y"). Since the Individual Y didn't exist in priv->individuals, it would be filtered out, and the IndividualStore would not receive the signal to remove that Individual. Next, the IndividualManager would try to remove Individual X, but priv->individuals would only contain Individual Y. In the end, all the correct Individuals would be removed from priv->individuals. The mix up in these removals is very odd, and I honestly can't explain it (I pored over the code quite a bit, but nothing stood out). In the end, this patch seems to fix this bug and seems relatively safe, so I think it's worth merging. If you would like to do so before the next release (in case I'm not available), please merge it yourself (assuming you approve it).
Looks reasonable to me. commit 17d384008361384be53a2466fcd9a7e837e10d09 Author: Travis Reitter <travis.reitter@collabora.co.uk> Date: Thu Aug 26 16:39:42 2010 -0700 Don't filter out Individual removal at the IndividualManager level. The IndividualManager sometimes falsely filters out members of FolksIndividualAggregator:individuals-changed:removed that should be passed along to its users. libempathy/empathy-individual-manager.c | 13 ++++--------- 1 files changed, 4 insertions(+), 9 deletions(-)
*** Bug 626411 has been marked as a duplicate of this bug. ***