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.
Also reported upstream in: http://bugs.camaya.net/horde3/whups/ticket/?id=202
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.
The newly released 1.0.2 version of gloox should have this bug fixed. http://camaya.net/news/gloox-1-0-2-released/
Are you willing update it in Fedora?
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.
gloox is active again. ;)
Who said? 1.0.3 out version is just bugfixing on my mind. Is not?