I got this stacktrace (without steps to reproduce):
#0 tp_handle_inspect(self=0x0, handle=12)
#1 gabble_roster_request_subscription_added_cb(source=0x1a2848, user_data=0x249d00)
On the terminal we get:
GLIB DEBUG default - send_iq_async failed: Error receiving data: Network is unreachable
GLIB CRITICAL ** tp-glib - tp_base_connection_get_handles: assertion `TP_IS_BASE_CONNECTION (self)' failed
What seems to happen is that we get disconnected, the connection goes away and it's null in the gabble_roster_request_subscription_added_cb() callback. Other similar callbacks in roster.c have a check for self->priv->conn not being NULL.
What I don't understand at all is how self->priv->conn can actually become NULL. It's set in the constructed() method and then never changed again, not even in dispose()/finalize():
gabble_roster_constructed (GObject *obj)
/* FIXME: This is not a strong reference because that would create a cycle.
* I'd like to have a cyclic reference and break it at disconnect time,
* like the contact list example in telepathy-glib does, but we can't do
* that because the rest of Gabble assumes that the roster remains useful
* until the bitter end (for instance, gabble_im_channel_dispose looks
* at the contact's subscription). */
self->priv->conn = GABBLE_CONNECTION (tp_base_contact_list_get_connection (
g_assert (GABBLE_IS_CONNECTION (self->priv->conn));
Note that the GAsyncResult passed to gabble_roster_request_subscription_added_cb() holds a reference to self, so it should not have been deleted in the meantime.
-- GitLab Migration Automatic Message --
This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.
You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-gabble/issues/177.