5.2.20
02/28/2020

[#202] Small C++ bug preventing succesful logins
Summary Small C++ bug preventing succesful logins
Queue gloox
Queue Version 1.0
Type Bug
State Resolved
Priority 3. High
Owners js (at) camaya (dot) net
Requester sqrt (at) entless (dot) org
Created 09/27/2012 (2710 days ago)
Due
Updated 07/05/2013 (2429 days ago)
Assigned
Resolved 07/05/2013 (2429 days ago)

History
07/05/2013 06:04:26 PM Jakob Schröter Comment #7
State ⇒ Resolved
Reply to this comment
Thanks again for the reports, this should now be fixed in gloox 1.0.1
02/13/2013 09:12:37 PM erik (at) ejohansson (dot) se Comment #6 Reply to this comment
I reported this bug in Fedora's bugzilla a few days ago: 
https://bugzilla.redhat.com/show_bug.cgi?id=909859

For me it helped to move the implementation from util.h to util.cpp.
01/10/2013 05:39:58 PM Jakob Schröter Comment #5
Assigned to Jakob Schröter
Reply to this comment
Thanks for the reports!
Could you please test with util.h from svn, gloox 1.0 branch? That one 
is more recent (unfortunately) and doesn't use log().

01/10/2013 04:44:55 PM sven (at) anderson (dot) de Comment #4
New Attachment: util.h.patch
Reply to this comment
I can confirm the bug in long2string(). I attached a version that does 
not need floating point operations.
The assignment of a temporary return value to a reference is not 
undefined behavior, the reference should persist as long as the 
temporary, and it was not the problem in this case.


01/09/2013 07:08:33 PM sven (at) anderson (dot) de Comment #3 Reply to this comment
It seems I'm observing the same bug on a Ubuntu 12.04 32-bit system, 
with both the libgloox that comes with ubuntu as well as a self 
compiled gloox 1.0. After receiving the bind result stanza from the 
server the login handshake stops and the connection times out after 
half a minute. Interestingly recompiling the lilbrary with either -O0 
or with -fno-strict-aliasing fixes the problem, but this could be just 
an coincidence in the case of undefined behaviour. But there is 
something wrong for sure. I saw other reports on the net of the same 
problem.

09/28/2012 12:30:28 PM sqrt (at) entless (dot) org Comment #2 Reply to this comment
Sorry, it turned out that wasn't the whole story; At least on 32-bit 
ubuntu, util::long2string(10, 10) returns "0" because the 
floating-point log function does not (and can not) handle integers 
with 100% precision: The computed string length (log_10(10) + 1) is 
just a tiny bit smaller than 1.0, but when converted to integer, it 
becomes 1;
This results in XTAttribute (which has the value 10), when converted 
into a tag attribute, being type="0" instead of type="10", and 
therefore the resource bind xmlns will not be recognized by the xpath.
09/27/2012 06:04:59 PM sqrt (at) entless (dot) org Comment #1
State ⇒ Unconfirmed
New Attachment: fix.patch
Queue ⇒ gloox
Summary ⇒ Small C++ bug preventing succesful logins
Type ⇒ Bug
Priority ⇒ 3. High
Reply to this comment
Tag::findTagList() returns a ConstTagList, however in 
stanzaextensionfactory.cpp:81 (trunk line number), its return value is 
assigned to "const ConstTagList& match"; This is undefined behaviour 
and has, on at least 2 installations of 32bit Ubuntu, prevented 
successul login, because resource bind stanza extensions were not 
detected.
Fixing the bug is trivial and a patch file has been attached.