Bug 909859 - Unable to bind resource after connecting to jabber server
Summary: Unable to bind resource after connecting to jabber server
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: gloox
Version: 17
Hardware: i686
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Pavel Alexeev
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-02-11 10:35 UTC by Erik Johansson
Modified: 2013-08-10 17:22 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-04-02 13:10:30 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

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?


Note You need to log in before you can comment on or make changes to this bug.