[Bug 52146] Crash when connection facebook account

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=52146

--- Comment #3 from Will Thompson <will.thompson at collabora.co.uk> ---
(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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.