64-bit libjingle failing to parse login XML with expat error: ERROR_INVALID_TOKEN

Question

Only upon attempting to run my login code under 64-bit, am I getting a failure to login to talk.google.com for my initial tests. 32-bit works fine.

Upon enabling logging macros and siginput logging, I can see that the XML it's failing on is this:

<stream:stream from="gmail.com" id="3D9A4487B8514DE2" version="1.0" xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client">\232\231\377

Inside expat I can see that there is an XML_ERROR_INVALID_TOKEN being thrown, but I'm not quite sure where to go from there. Sometimes it makes it to an actual login but dies shortly after. It appears to be relatively random, but always dies within the first 10 responses or so. I recognize that the junk data at the end is what is probably causing the invalid token, but am not sure what causes it.

My initial thought was an encoding issue upon switching to 64-bit (??), but honestly, I just don't know what would cause something like that to happen.

Here is an additional example snippet from the logs that libjingle dies on:

137[000:568] RECV <<<<<<<<<<<<<<<<<<<<<<<<< : Thu Feb 21 00:01:31 2013
[000:568]    \332
[000:568]    <iq id="2" type="result">
[000:568]      <bind xmlns="urn:ietf:params:xml:ns:xmpp-bind">
[000:568]        <jid>
[000:568]          snip@gmail.com/CD6FF
[000:568]        </jid>
[000:568]      </bind>
[000:568]    </iq>
<iq id="2" type="result"><bind xmlns="urn:ietf:params:xml:ns:xmpp-bind"><jid>snip@gmail.com/CD6FF</jid></bind></iq>x\332Mhanism>X-OAUTH2</mechanism></mechanisms></stream:features>p

And another:

[000:217]    <stream:stream from="gmail.com" id="2462F624C942" version="1.0" xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client">
<stream:stream from="gmail.com" id="246E4B24C942" version="1.0" xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client">\225\231\377

Another:

139[000:178] RECV <<<<<<<<<<<<<<<<<<<<<<<<< : Thu Feb 21 00:20:52 2013
[000:178]    <stream:stream from="gmail.com" id="B15C99514B664586" version="1.0" xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client">
<stream:stream from="gmail.com" id="B15C99514B664586" version="1.0" xmlns:stream="http://etherx.jabber.org/streams" xmlns="jabber:client">\366\231\377

Another:

52[000:243] RECV <<<<<<<<<<<<<<<<<<<<<<<<< : Thu Feb 21 00:23:44 2013
[000:243]    Q
[000:243]    <success xmlns="urn:ietf:params:xml:ns:xmpp-sasl"/>
<success xmlns="urn:ietf:params:xml:ns:xmpp-sasl"/>\261xml:ns:xmpp-sasl"><mechanism>PLAIN</mechanism><mechanism>X-GOOGLE-TOKEN</mechanism><mechanism>X-OAUTH2</mechanism></mechanisms></stream:features>Q

Anyone run into this type of issue before?

Answer 1

Looks like this was a problem with the openssl 64 bit build I was using. No idea what was wrong with the build, but all I had to do was switch to the libssl.0.9.8, and libcrypto.0.9.8 dylib versions and everything works great.

Hopefully, this will help others diagnose strange junk in SSL interactions.

Answer 2

assuming that \ddd sequences represent octal numbers, your streams contain code points in invalid utf-8 which might be the default expected encoding for the xml data streams.

before feeding the content to the xml parser you'd have to replace the offending bytes by numerical entities, e.g. \231 -> ™.

another option might be to prefix your xml data stream with a xml prolog declaring some 8bit-charset, eg. <?xml version="1.0" encoding="iso-8859-1" ?>.

hope it helps, regards