When I join jabber@conference.jabber.org gabble and empathy crash. Looking at gabble messages I see that: ** ERROR:(presence-cache.c:1227):gabble_presence_cache_get: assertion failed: (tp_handle_is_valid (contact_repo, handle, NULL)) Abandon (core dumped) So it seems gabble assert for a wrong handle. Even if empathy sends bogus handles gabble shouldn't use g_assert for that but g_return_if_fail(). From empathy I see that: ... TpChat: Message pending: lol TpContactFactory: Contact added: (null) (78) ... TpContactFactory: Failed to inspect handles: handle 78 is not currently a valid contact handle (type 1) TpContactFactory: Failed to hold handles: handle 78 is not currently a valid contact handle (type 1) TpContactFactory: Error getting presence: handle 78 is not currently a valid contact handle (type 1) TpContactFactory: Error requesting aliases: handle 78 is not currently a valid contact handle (type 1) TpContactFactory: Error getting known avatars tokens: handle 78 is not currently a valid contact handle (type 1) TpContactFactory: Error getting capabilities: handle 78 is not currently a valid contact handle (type 1) So empathy receives a message "lol" (muc backlog) from the handle "78" then gabble returns an error for everything I ask for that handle... Note that this message is the first backlog message I get when joining the room and all other messages comes from different handles and gabble accept them as valid handles.
The handle is probably one that exists in the backlog, but is not in the chatroom any more, so it's only ref'd while it's in the pending messages list. Another part in the ongoing handle-validity nightmare... The following sequence of calls by Empathy would work correctly (the only failure case I can think of is someone else is acknowledging the messages too): * get the Received signal, or ListPendingMessages * hold the handle with HoldHandles * *only then* acknowledge the message Gabble should not be using either assert or return_if_fail for this sort of thing - return_if_fail is an assertion too, and it's inappropriate to assert about anything received from outside the process. It should just be returning the InvalidHandle error, like it did to produce the various lines tagged "TpContact" in your log.
Also, please can you provide a backtrace (and ideally a Gabble log) when reporting any assertion?
*** Bug 14913 has been marked as a duplicate of this bug. ***
*** New message with type="iq" from: jabber@conference.jabber.org tp_properties_mixin_emit_changed: emitting properties changed for properties: anonymous invite-only moderated name description password-required persistent private tp_properties_mixin_emit_flags: emitting properties flags changed for properties: anonymous's flags now: [READ] invite-only's flags now: [READ] moderated's flags now: [READ] name's flags now: [READ] description's flags now: [READ] password-required's flags now: [READ] persistent's flags now: [READ] private's flags now: [READ] (telepathy-gabble:23744): tp-glib-DEBUG: tp_presence_mixin_get_presence: called. (telepathy-gabble:23744): tp-glib-DEBUG: construct_presence_hash: called. (telepathy-gabble:23744): tp-glib-DEBUG: tp_presence_mixin_get_presence: called. (telepathy-gabble:23744): tp-glib-DEBUG: construct_presence_hash: called. (telepathy-gabble:23744): tp-glib-DEBUG: tp_presence_mixin_get_presence: called. ** ** ERROR:(presence-cache.c:1227):gabble_presence_cache_get: assertion failed: (tp_handle_is_valid (contact_repo, handle, NULL)) Program received signal SIGABRT, Aborted. 0x00007febcdd280e5 in raise () from /lib/libc.so.6 (gdb) bt #0 0x00007febcdd280e5 in raise () from /lib/libc.so.6 #1 0x00007febcdd29b40 in abort () from /lib/libc.so.6 #2 0x00007febce0b1b17 in g_assertion_message () from /usr/lib/libglib-2.0.so.0 #3 0x00007febce0b1fb2 in g_assertion_message_expr () from /usr/lib/libglib-2.0.so.0 #4 0x0000000000418f9b in gabble_presence_cache_get (cache=<value optimized out>, handle=37) at presence-cache.c:1227 #5 0x000000000040f7c6 in gabble_connection_get_capabilities (iface=0x689080, handles=0x6a8c80, context=0x6ab3b0) at gabble-connection.c:2276 #6 0x00007febce7a5144 in gobject_message_function (connection=0x67e560, message=0x6a2c50, user_data=<value optimized out>) at dbus-gobject.c:1160 #7 0x00007febce575a79 in ?? () from /usr/lib/libdbus-1.so.3 #8 0x00007febce569137 in dbus_connection_dispatch () from /usr/lib/libdbus-1.so.3 #9 0x00007febce7a1f75 in message_queue_dispatch (source=<value optimized out>, callback=<value optimized out>, user_data=<value optimized out>) at dbus-gmain.c:101 #10 0x00007febce08f222 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #11 0x00007febce0924d6 in ?? () from /usr/lib/libglib-2.0.so.0 #12 0x00007febce092797 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 #13 0x00007febcea18b04 in tp_run_connection_manager (prog_name=<value optimized out>, version=0x44fc21 "0.7.2", construct_cm=0x40dc70 <construct_cm>, argc=<value optimized out>, argv=<value optimized out>) at run.c:238 #14 0x00007febcdd141c4 in __libc_start_main () from /lib/libc.so.6 #15 0x000000000040db59 in _start ()
Fixed in 0.7.4
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.