[jdev] Bug in jabberd2 (2.1.13) on win32

[Dan Hulme]

I have run into a strange bug with the win32 version of jabberd2 (2.1.13).
after disconnecting with some clients, the next client to connect hangs
after that, the next client works fine again
after tracking down the behavior, I found that removing the following
line fixed the problem

sx/io.c:149             s->want_write = 1;

when a stream closes, and this is set, it seems to hang the next connection

A similar bug is caused at

error.c:85              s->want_write = 1;

When a client is disconnected because of a bad stream/packet, this
occurs, and disconnects the client.  But, the next client cannot
connect again.

Some clients, such as PSI, do not cause this problem when
disconnecting.  It appears to be because they do not send a final
</stream:stream> tag before disconnecting.

To duplicate the bug, connect to a win32 jabberd2 server with
cocinella.  Disconnect.  Try to connect again.  The second connection
will hang and eventually fail.  Try to connect again, and it will work
again.  If you telnet to the server in this state, it will not respond
to anything you send it.

Initially, I used the provided win32 build (336) on nanoant.com.  This
fails suitably for the test.

Next, I tried building 2.1.21 on win32.  The build doesn't work
without some fixes to the code.  Once I got it working, it had the
same problem.

Currently, I am using 2.1.13 on win32.  I have built it myself and it
works almost without changing anything.  It has the bug, as well.  My
line numbers above refer to this version.

I don't pretend to understand everything that's going on in the code.
However, I have tried with sasl on, sasl off, plainttext, etc., and no
options seem to change this problem.  So it seems a fairly basic
problem in jabberd2, and probably not related to plugins.  Does
deactivating "want_write" prevent the session close information from
being sent or recorded?  I don't know, but everything seems to work
correctly even with that line commented.

I'm unsure of what to try next in order to "correctly" fix the
problem.  Perhaps the developers can take this and run with it.  I'm
guessing that it has trouble "writing" to a closed session or
something like that.

-Dan