Btw, did you notice that inside the function libssh2_blocking_read() look at
line 690:
if (ret == 0) continue;
Where ret is the return status of recv() being called above. Now if recv()
returns 0, this means that no messages are available to be received and the
peer has performed an orderly shutdown. Whereas here we just continue in the
while loop!
Won't this lead to an infinite hang as the remote server has already closed
the connection? Perhaps we may want to treat (ret=0) also as a failure case
and return -1 from blocking_read.
On 11/10/06, Satish Mittal <satish.mittal_at_gmail.com> wrote:
>
>
>
> On 11/10/06, Daniel Stenberg <daniel_at_haxx.se> wrote:
> >
> > On Fri, 10 Nov 2006, Satish Mittal wrote:
> >
> > > I think for sanity, apart from your fix we also need to initialize the
> > > buf[24] array created on stack to all fields zero (in line 874).
> >
> > > In my case, the problem was because libssh2_blocking_read was failing
> > and
> > > returning -1, which was assigned to an unsigned long. James seems to
> > fix
> > > that, but to me it looks to be more of an implementation problem at
> > SSH
> > > transport layer protocol itself!
> >
> > I think first we should make sure we check all calls to
> > libssh2_blocking_read() for a -1 returned and then bail out if so. The
> > way the
> > 0.14 code just adds the return code to the current number is outright...
> > weird.
> >
> > With that fixed, I don't see why we would need to zero the array?
> >
>
> Ya, once we catch all the blocking_read failure status, then hopefully we
> shouldn't need to care about zeroing the array.
>
>
> --
> "The happiest of people don´t necessarily have the best of everything,
> they just make the most of everything that comes along their way."
>
-- "The happiest of people don´t necessarily have the best of everything, they just make the most of everything that comes along their way."Received on 2006-11-10