| Summary: | Crash when connection facebook account | ||
|---|---|---|---|
| Product: | Telepathy | Reporter: | Xavier Claessens <xclaesse> |
| Component: | gabble | Assignee: | Telepathy bugs list <telepathy-bugs> |
| Status: | RESOLVED FIXED | QA Contact: | Telepathy bugs list <telepathy-bugs> |
| Severity: | normal | ||
| Priority: | medium | CC: | s9iper1, will |
| Version: | unspecified | Keywords: | patch |
| Hardware: | Other | ||
| OS: | All | ||
| URL: | http://cgit.collabora.com/git/user/wjt/telepathy-gabble/log/?h=52146-auth-close-then-receive-challenge | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
|
Description
Xavier Claessens
2012-07-16 09:59:56 UTC
*** 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.