_caps_disco_cb calls g_str_equal, which is not null-safe.
Note that this is causing the echobot to fall over too. For the interested, the thing that triggers it is a missing form type. I wrote a test at http://cgit.freedesktop.org/~alsuren/wocky/commit/?h=qutim-caps-39464 in case anyone knows what the right thing to do here is. I suspect that the answer is just file a bug against qutim.
My reading of XEP-0004 is that the type='' attribute is mandatory, and that in this case it ought really to be result. <http://xmpp.org/extensions/xep-0004.html#protocol-formtypes> describes type='result' as “… the data is a generic data set.”. <http://xmpp.org/extensions/xep-0004.html#schema> says that the type='' attribute is mandatory. So qutim is buggy. But clearly so are we. :) Your patch looks good; here's a regression test for Gabble: <http://cgit.collabora.com/git/user/wjt/telepathy-gabble-wjt.git/commit/?h=null-caps-39464>. The regression test's form is malformed in more crucial ways, too: the form type='' attribute is not part of the XEP-0115 hash, but the FORM_TYPE field (which is different!) is, so omitting it makes for a genuinely unhashable disco reply, even in the presence of a fault-tolerant parser. I tweaked Wocky to accept the absence of type='' (which I don't think we should do, but some future person might) and the test still passed without crashing Gabble, so that's fine then.
*** Bug 39652 has been marked as a duplicate of this bug. ***
Merged to master. Does not affect 0.12.
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.