Bug 909859

Summary: Unable to bind resource after connecting to jabber server
Product: [Fedora] Fedora Reporter: Erik Johansson <erik>
Component: glooxAssignee: Pavel Alexeev <pahan>
Status: CLOSED UPSTREAM QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 17CC: i, pahan
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-04-02 13:10:30 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Erik Johansson 2013-02-11 10:35:55 UTC
Description of problem:
After connecting to a jabber server (in my case talk.google.com), the client tries to bind a resource and receives a response from the server. The response is well-formed, but gloox fails to parse it correctly.

This simple test program can be used to reproduce the original problem:

#include <cassert>
#include <gloox/parser.h>

class TagHandler : public gloox::TagHandler
{
public:
  void handleTag(gloox::Tag* tag)
  {
    std::string filter = "/bind[@xmlns='urn:ietf:params:xml:ns:xmpp-bind']";
    const gloox::ConstTagList& match = tag->findTagList(filter);
    assert(!match.empty());
  }
};

int main()
{
  TagHandler tagHandler;
  gloox::Parser parser(&tagHandler);

  std::string xml = "<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'/>";
  parser.feed(xml);

  return 0;
}

# g++ -o tagtest tagtest.cpp -lgloox && ./tagtest
tagtest: tagtest.cpp:12: virtual void TagHandler::handleTag(gloox::Tag*): Assertion `!match.empty()' failed.

After tracing it, the problem seems to be that gloox::util::long2string returns "0" when passed the value 10 which seem to come from len getting the value 1 instead of 2.

Moving the implementation of long2string from the header to util.cpp fixes the problem.


Version-Release number of selected component (if applicable):
gloox-1.0-3.11.fc17.i686
gloox-devel-1.0-3.11.fc17.i686


How reproducible:
Always


Steps to Reproduce:
1. Run licq (with -d 31) and try to connect to talk.google.com

(I've only tested latest licq from upstream git repository.)


Actual results:
The connect process hangs after receiving the well-formed bind response.


Expected results:
The client connects and fetches contacts.


Additional info:
The same licq version and gloox version work when run on ubuntu 12.10.

Comment 1 Erik Johansson 2013-02-13 21:04:55 UTC
Also reported upstream in: http://bugs.camaya.net/horde3/whups/ticket/?id=202

Comment 2 Pavel Alexeev 2013-04-02 13:10:30 UTC
Thank you for your bugreport and willing make free software better!

We close bug now, as it related to upstream developing. But we continue track changes and whatever it will be fixed ve consider make update in Fedora.

Meantime as I known gloox does not developed anymore. Instead developer switched to jreen library which gloox successor.

Comment 3 Erik Johansson 2013-07-08 20:39:20 UTC
The newly released 1.0.2 version of gloox should have this bug fixed.

http://camaya.net/news/gloox-1-0-2-released/

Comment 4 Pavel Alexeev 2013-07-14 18:05:37 UTC
Are you willing update it in Fedora?

Comment 5 Pavel Alexeev 2013-07-14 18:07:25 UTC
In any case, gloox development if I understand correctly mostly stopped. You may look at jreen an replacer of gloox on qutim project. It have similar API.

Comment 6 Christopher Meng 2013-08-05 06:27:39 UTC
gloox is active again. ;)

Comment 7 Pavel Alexeev 2013-08-10 17:22:48 UTC
Who said? 1.0.3 out version is just bugfixing on my mind. Is not?