This crash happens if empathy-auth-client crash while doing the facebook auth, which cause the channel to be closed, then wocky receive the challenge and assert: (telepathy-gabble:1192): wocky-DEBUG: Writing xml: <auth wocky-zb:client-uses-full-bind-result="true" mechanism="X-FACEBOOK-PLATFORM" xmlns:wocky-zb="http://www.google.com/talk/protocol/auth" xmlns="urn:ietf:params:xml:ns:xmpp-sasl"/> (telepathy-gabble:1192): tp-glib/channel-DEBUG: tp_base_channel_close_dbus: called by :1.184 (telepathy-gabble:1192): gabble-DEBUG: gabble_server_tls_channel_close (server-tls-channel.c:305): Close() called on the TLS channel 0x10a6a40 (telepathy-gabble:1192): gabble-DEBUG: server_tls_channel_closed_cb (server-tls-manager.c:197): Server TLS channel closed. (telepathy-gabble:1192): gabble-DEBUG: gabble_server_tls_channel_dispose (server-tls-channel.c:144): Dispose TLS channel (telepathy-gabble:1192): gabble-DEBUG: gabble_server_tls_channel_finalize (server-tls-channel.c:127): Finalize TLS channel (telepathy-gabble:1192): tp-glib/channel-DEBUG: tp_base_channel_close_dbus: called by :1.184 (telepathy-gabble:1192): gabble-DEBUG: gabble_server_sasl_channel_close (server-sasl-channel.c:958): called on 0x10a6ad0 (telepathy-gabble:1192): wocky-DEBUG: Parsing chunk: <challenge xmlns="urn:ietf:params:xml:ns:xmpp-sasl">dmVyc2lvbj0xJm1ldGhvZD1hdXRoLnhtcHBfbG9naW4mbm9uY2U9QkYxNjRFMDE1OTkxRjdBQkIzMUIyOUYxQzAxNTUyQkU=</challenge> (telepathy-gabble:1192): wocky-DEBUG: _end_element_ns: Received stanza * challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl' "dmVyc2lvbj0xJm1ldGhvZD1hdXRoLnhtcHBfbG9naW4mbm9uY2U9QkYxNjRFMDE1OTkxRjdBQkIzMUIyOUYxQzAxNTUyQkU=" ** wocky:ERROR:wocky-auth-registry.c:426:wocky_auth_registry_challenge_async_func: assertion failed: (priv->handler != NULL) Program received signal SIGABRT, Aborted. 0x00007ffff5b9f445 in raise () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) bt #0 0x00007ffff5b9f445 in raise () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x00007ffff5ba2bab in abort () from /lib/x86_64-linux-gnu/libc.so.6 #2 0x00007ffff5f8ed97 in g_assertion_message (domain=domain@entry=0x7ffff730b93b "wocky", file=file@entry=0x7ffff730ba1a "wocky-auth-registry.c", line=line@entry=426, func=func@entry=0x7ffff730bde0 "wocky_auth_registry_challenge_async_func", message=<optimized out>) at /build/buildd/glib2.0-2.33.3/./glib/gtestutils.c:1861 #3 0x00007ffff5f8f2b4 in g_assertion_message_expr (domain=domain@entry=0x7ffff730b93b "wocky", file=file@entry=0x7ffff730ba1a "wocky-auth-registry.c", line=line@entry=426, func=func@entry=0x7ffff730bde0 "wocky_auth_registry_challenge_async_func", expr=expr@entry=0x7ffff730ba04 "priv->handler != NULL") at /build/buildd/glib2.0-2.33.3/./glib/gtestutils.c:1872 #4 0x00007ffff72d6b2e in wocky_auth_registry_challenge_async_func (self=<optimized out>, challenge_data=0x76b680, callback=0x7ffff72fbe70 <wocky_sasl_auth_response_cb>, user_data=0xafc980) at wocky-auth-registry.c:426 #5 0x00007ffff72fc17b in sasl_auth_stanza_received (source=<optimized out>, res=<optimized out>, user_data=user_data@entry=0xafc980) at wocky-sasl-auth.c:562 #6 0x00007ffff66e3fae in g_simple_async_result_complete (simple=0xa5f040) at /build/buildd/glib2.0-2.33.3/./gio/gsimpleasyncresult.c:767 #7 0x00007ffff73035e8 in _xmpp_connection_received_data (source=0x726040, result=0x7a9c20, user_data=<optimized out>) at wocky-xmpp-connection.c:562 #8 0x00007ffff66cebe4 in async_ready_callback_wrapper (source_object=0x726040, res=0x7a9c20, user_data=0xe29110) at /build/buildd/glib2.0-2.33.3/./gio/ginputstream.c:529 #9 0x00007ffff66e3fae in g_simple_async_result_complete (simple=0x7a9c20) at /build/buildd/glib2.0-2.33.3/./gio/gsimpleasyncresult.c:767 #10 0x00007ffff7307436 in wocky_tls_job_result_gssize (job=<optimized out>, result=160) at wocky-tls.c:369 #11 0x00007ffff66cebe4 in async_ready_callback_wrapper (source_object=0x7a9d70, res=0x75d070, user_data=0x742480) at /build/buildd/glib2.0-2.33.3/./gio/ginputstream.c:529 #12 0x00007ffff66e3fae in g_simple_async_result_complete (simple=0x75d070) at /build/buildd/glib2.0-2.33.3/./gio/gsimpleasyncresult.c:767 #13 0x00007ffff66e40dc in complete_in_idle_cb (data=0x75d070) at /build/buildd/glib2.0-2.33.3/./gio/gsimpleasyncresult.c:779 #14 0x00007ffff5f6d8b5 in g_main_dispatch (context=0x72be60) at /build/buildd/glib2.0-2.33.3/./glib/gmain.c:2539 #15 g_main_context_dispatch (context=context@entry=0x72be60) at /build/buildd/glib2.0-2.33.3/./glib/gmain.c:3075 #16 0x00007ffff5f6dbe8 in g_main_context_iterate (context=0x72be60, block=block@entry=1, dispatch=dispatch@entry=1, self=<error reading variable: Unhandled dwarf expression opcode 0xfa>) at /build/buildd/glib2.0-2.33.3/./glib/gmain.c:3146 #17 0x00007ffff5f6dfe2 in g_main_loop_run (loop=0x732270) at /build/buildd/glib2.0-2.33.3/./glib/gmain.c:3340 #18 0x00007ffff6ff0b52 in tp_run_connection_manager () from /usr/lib/x86_64-linux-gnu/libtelepathy-glib.so.0 #19 0x0000000000428c7c in gabble_main (argc=1, argv=0x7fffffffe068) at gabble.c:179 #20 0x00007ffff5b8a76d in __libc_start_main () from /lib/x86_64-linux-gnu/libc.so.6 #21 0x0000000000428899 in _start ()
*** Bug 53183 has been marked as a duplicate of this bug. ***
This was easy enough to write a regression test for: <http://cgit.collabora.com/git/user/wjt/telepathy-gabble/commit/?h=52146-auth-close-then-receive-challenge>. The crash is inside Wocky's SASL goop somewhere. I notice that the client is meant to send <abort> when it gives up on the SASL exchange, and the server then sends back <failure><aborted>. <http://xmpp.org/rfcs/rfc6120.html#sasl-process-neg-abort> But there is no evidence of anything in Gabble or Wocky ever sending <abort>. Which is pretty cool.
(In reply to comment #2) > This was easy enough to write a regression test for: > <http://cgit.collabora.com/git/user/wjt/telepathy-gabble/commit/?h=52146- > auth-close-then-receive-challenge>. > > The crash is inside Wocky's SASL goop somewhere. I notice that the client is > meant to send <abort> when it gives up on the SASL exchange, and the server > then sends back <failure><aborted>. > <http://xmpp.org/rfcs/rfc6120.html#sasl-process-neg-abort> > > But there is no evidence of anything in Gabble or Wocky ever sending > <abort>. Which is pretty cool. Gabble subclasses WockyAuthRegistry, which is used by WockySaslAuth (and WockyJabberAuth). WockyAuthRegistry has methods called by WockySaslAuth in response to some protocol events: • start_auth_async • challenge_async • success_async but while WockySaslAuth is waiting for something from the server, rather than for one of those to return, there is no way for WockyAuthRegistry to signal that it's given up. In this scenario, GabbleAuthManager has returned from start_auth_async by the time the channel dies. The next opportunity it has to signal something up to WockySaslAuth is when gabble_auth_manager_challenge_async() is called. But what happens in gabble_auth_manager_challenge_async() is: if (self->priv->channel != NULL && !self->priv->falling_back) self->priv->channel is NULL, so even though we are not falling back, we fall through to the else branch: WOCKY_AUTH_REGISTRY_CLASS ( gabble_auth_manager_parent_class)->challenge_async_func ( registry, challenge_data, callback, user_data); which is where we crash, because the parent's start_auth_async_func() never got called so no handler was ever chosen.
This was surprisingly involved to fix, but I'm pretty confident that my comprehensive set of test cases has teased out all the crashes.
I've merged this to master for 0.17.2. I don't particularly want to merge the fix to 0.16, because it is relatively big, and only happens when another component crashes.
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.