From 9f104cd8838e193a38e53da51a236ab4cb66ac5b Mon Sep 17 00:00:00 2001 From: Daniel Stenberg Date: Thu, 30 Apr 2009 10:30:26 +0000 Subject: [PATCH] Markus posted a bug report about a bad 0-return from libssh2_channel_read: http://libssh2.haxx.se/mail/libssh2-devel-archive-2009-04/0076.shtml And it was indeed a bad loop that terminated too early due to a receveived close packet. --- NEWS | 8 ++++++++ src/channel.c | 9 ++++++++- 2 files changed, 16 insertions(+), 1 deletion(-) diff --git a/NEWS b/NEWS index 4561d3a4..464f87b5 100644 --- a/NEWS +++ b/NEWS @@ -1,4 +1,12 @@ +* (Apr 30 2009) Daniel Stenberg: + + Markus posted a bug report about a bad 0-return from libssh2_channel_read: + http://libssh2.haxx.se/mail/libssh2-devel-archive-2009-04/0076.shtml + + And it was indeed a bad loop that terminated too early due to a receveived + close packet. + * (Apr 14 2009) Daniel Stenberg: libssh2_poll() and libssh2_poll_channel_read() are now considered and diff --git a/src/channel.c b/src/channel.c index ef5da4cc..6c1a2108 100644 --- a/src/channel.c +++ b/src/channel.c @@ -1794,8 +1794,15 @@ static ssize_t channel_read(LIBSSH2_CHANNEL *channel, int stream_id, channel->read_packet = session->packets.head; while (channel->read_packet && - !channel->remote.close && (bytes_read < (int) buflen)) { + /* previously this loop condition also checked for + !channel->remote.close but we cannot let it do this: + + We may have a series of packets to read that are still pending even + if a close has been received. Acknowledging the close too early + makes us flush buffers prematurely and loose data. + */ + LIBSSH2_PACKET *readpkt = channel->read_packet; /* In case packet gets destroyed during this iteration */