telepathy-gabble crashed with SIGABRT in g_assertion_message()

Bug #1102394 reported by Daniel Holbach on 2013-01-21
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Fix Released
telepathy-gabble (Ubuntu)

Bug Description

No idea what happened.

ProblemType: Crash
DistroRelease: Ubuntu 13.04
Package: telepathy-gabble 0.16.1-2
ProcVersionSignature: Ubuntu 3.8.0-1.5-generic 3.8.0-rc4
Uname: Linux 3.8.0-1-generic x86_64
ApportVersion: 2.8-0ubuntu2
Architecture: amd64
CheckboxSubmission: 2f383a1679e8525d7196eb2518a1921f
CheckboxSystem: bb422ca46d02494cdbc459927a98bc2f
Date: Mon Jan 21 14:15:30 2013
ExecutablePath: /usr/lib/telepathy/telepathy-gabble
InstallationDate: Installed on 2011-08-19 (521 days ago)
InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Alpha amd64 (20110817)
MarkForUpload: True
ProcCmdline: /usr/lib/telepathy/telepathy-gabble
Signal: 6
SourcePackage: telepathy-gabble
 g_assertion_message () from /lib/x86_64-linux-gnu/
 g_assertion_message_expr () from /lib/x86_64-linux-gnu/
 ?? () from /usr/lib/telepathy/gabble-0/lib/
 ?? () from /usr/lib/telepathy/gabble-0/lib/
 g_simple_async_result_complete () from /usr/lib/x86_64-linux-gnu/
Title: telepathy-gabble crashed with SIGABRT in g_assertion_message()
UpgradeStatus: Upgraded to raring on 2013-01-17 (4 days ago)
UserGroups: adm admin audio cdrom dialout lpadmin plugdev sambashare utah

Download full text (5.0 KiB)

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="" 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'
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/
(gdb) bt
#0 0x00007ffff5b9f445 in raise () from /lib/x86_64-linux-gnu/
#1 0x00007ffff5ba2bab in abort () from /lib/x86_64-linux-gnu/
#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...


*** Bug 53183 has been marked as a duplicate of this bug. ***

This was easy enough to write a regression test for: <>.

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

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

          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.

Daniel Holbach (dholbach) wrote :
Changed in telepathy-gabble (Ubuntu):
importance: Undecided → Medium
tags: removed: need-amd64-retrace
information type: Private → Public
Sebastien Bacher (seb128) wrote :

The issue is fixed upstream in telepathy-gabble 0.17

Changed in telepathy-gabble (Ubuntu):
importance: Medium → High
status: New → Fix Committed
Changed in telepathy-gabble:
importance: Unknown → Medium
status: Unknown → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.