On Tue, 4 Aug 2009, Alexander Lamaison wrote:
> $ git bisect good
> b95fe985af3c80a2babcaaaf7da69a15b1237c49 is first bad commit
> commit b95fe985af3c80a2babcaaaf7da69a15b1237c49
Okay, so here comes some more testing and thougths.
First, I attach a patch that is a reversal of the mentioned commit - EXCEPT
two important edits (see below).
It would be very interesting to hear how this patch changes behavior, or not.
This reverts my code that makes it treat a short read as the end of data to
read, and goes back to always read until EAGAIN basically. I have a suspicion
that this won't make anything different.
This reversion patch leaves two changes in: the clearing of the direction bits
for EAGAIN situations. And as Peter noticed before, we did spot a case where
none of the bits were set even though libssh2 returned EAGAIN so quite
possibly this forced clearing is what triggered the problem. This will be
noticable if the problem remains after this patch has been applied.
A second test would of course to not apply this test, but to simply remove the
default clearing of the direction bits and see if that makes things run
better.
If the clearing of the bits is what triggers this problem, then we really need
to investigate how on earth libssh2 can return EAGAIN without setting the
bits. A theory: we call a function that returns a pointer and then in the
BLOCK_ADJUST_ERRNO macro, libssh2_session_last_errno() is called to see if the
reason for the NULL was an EAGAIN situation. Perhaps that function wrongly
returns EAGAIN simply because it hasn't been cleared properly since the
previous situation when EAGAIN was returned?
-- / daniel.haxx.se
_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel