Bug#631729: irssi-plugin-xmpp: Memory corruption and crash with /xmppconnect

[Cyril Brulebois]

Hello,

Florian Schlichting <fschlich at ZEDAT.FU-Berlin.DE> (23/01/2013):
> > As this only happens for me when connecting to a host that resolves to
> > both ipv4 and ipv6 (for irssi-plugin-xmpp that is: '/xmppconnect -h
> > localhost <jid>', NOT '/xmppconnect -h 127.0.0.1 <jid>'), I suppose the
> > GIO watch is triggered once for each protocol version. This may either
> > be a bug in glib, or needs to be caught in libloudmouth.
> 
> I now realize that things may be a bit more complicated than that, as
> connections to e.g. 'invalid at twattle.net' result in a faultless ipv6
> connection that continues all the way through to the password prompt.
> 
> Perhaps the issue is limited to cases where the name resolution happens
> via /etc/hosts, and returns results for both protocols? (It is *not*
> limited to connections to "localhost", it also happens when /etc/hosts
> specifies both an ipv4 and an ipv6 address for a remote host.)
> 
> And KiBi, is your use case covered by these considerations?

thanks, that definitely helps. Trying to find where the regression
came from, I couldn't find any irssi/xmpp plugin/loudmouth/libasyncns
combination allowing me to get back a connection to my server; I even
went back to squeeze, and nothing worked. That IPv6 lead looks
promising as the bug reporting date is consistent with the IPv6 tunnel
request on the server side, according to sixxs' web interface.

As for /etc/hosts, I got DNS returning both IPv4 and IPv6 for
“mraw.org”; forcing IPv4 only through /etc/hosts leads to a successful
connection. Having both IPv4 and IPv6 in there leads to the same kind
of breakages. Forcing IPv6 only through /etc/hosts leads to no failure,
even if I can check good behaviour for real since ejabberd isn't IPv6
enabled by default, and I'm having troubles making it behave properly
on restart (even with its original config).

So yeah, double-stack (through DNS and/or /etc/hosts) seems to be the
ultimate culprit here.

Mraw,
KiBi.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnome-maintainers/attachments/20130123/48539bee/attachment.pgp>