Comment 11 for bug 1102394

(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.