www.libssh2.org | Daily snapshots | Mailing list archive | Docs | Examples

Archive Index This month's Index

Subject: Bug in channel.c/channel_request_pty_size?

Bug in channel.c/channel_request_pty_size?

From: Steve Legg <smlegg_at_googlemail.com>
Date: Fri, 31 Dec 2010 15:48:53 -0000

Hi,

In channel.c/channel_request_pty_size if the request to resize the pty is
successfully sent then channel->reqPTY_state ends up being set to
libssh2_NB_state_sent. However, I believe this is wrong. There doesn't
seem to be a way for reqPTY_state to ever be set back to idle after this so
the next call to libssh2_request_pty_size will fail (because the state is
still set to "sent") - the failure will cause the state to be set back to
idle, so the next call will succeed.

The upshot of this is that every odd call to libssh2_request_pty_size fails
and returns -1, every even call succeeds (and in fact - any other call that
uses reqPTY_state to track its state will also fail after a successful call
to libssh2_request_pty_size).

This bug is happening for me in libssh2-1.2.7 but looking at the repo,
although the code has been somewhat refactored, the same bug still appears
to be present.

A workaround for this bug is to simply call libssh2_request_pty_size again
if it returns -1:

        int r;
        if ((r=libssh2_request_pty_size(...))<0)
        {
                r=libssh2_request_pty_size(...);
        }

        .. normal error processing ...

But obviously that's not really very nice (and I'm not sure what evilness
will happen if a real error happens in the first call ;).

Am I wrong, and there is actually a way for reqPTY_state to be set back to
idle? Or is this a real bug? (it looks to me like the code has been written
with asynchrony in mind, but never actually finished - the reqPTY_state code
appears to be mostly redundant).

Thanks,
Steve.

_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
Received on 2010-12-31

the libssh2 team