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

Archive Index This month's Index

Subject: Re: sharing experiences with nonblocking exec and NVAL from libssh2_channel_wait_closed() with community

Re: sharing experiences with nonblocking exec and NVAL from libssh2_channel_wait_closed() with community

From: Steven Dake <sdake_at_redhat.com>
Date: Sun, 26 Feb 2012 11:07:31 -0700

On 02/26/2012 08:21 AM, Steven Dake wrote:
> On 02/25/2012 12:19 PM, Peter Stuge wrote:
>> Steven Dake wrote:
>>> The reason for the enter back into the read state is that
>>> libssh2_channel_wait_closed() checks for eof, and even though the code
>>> has already checked and passed the EOF state, further packets appear to
>>> be sent on the channel.
>>
>> I'm not sure if that is allowed. What packets are sent?
>>
> 97
>
>>
>>> This seems like some kind of odd race condition to me,
>>
>> Can you show libssh2 trace output from this happening?
>>
>>
>
> Turns out I was wrong with "read" fixing up the connection. My code
> actually has a timer (5 seconds) on the ssh connection and eventually
> times out the connection on the return of -34. The packet which is sent
> is 97 (close). The offending code is at channelc:2179:
> while (packet) {
> if (((packet->data[0] == SSH_MSG_CHANNEL_DATA)
> || (packet->data[0] == SSH_MSG_CHANNEL_EXTENDED_DATA))
> && (channel->local.id == _libssh2_ntohu32(packet->data + 1))) {
> /* There's data waiting to be read yet, mask the EOF status */
> return 0;
> }
> packet = _libssh2_list_next(&packet->node);
> }
>
>
> (the return 0)
>
> I have attached the typescript of the scenario happening.
>
> One thing that I noticed after looking at the typescript with libssh2
> tracing is that my code may be doing two execs on the same session at
> the same time (in a nonblocking way).
>
> I had assumed two outstanding execs would be safe - is that assumption
> correct? Could also relate to my packet leaking..
>
Further follow up on this point. I changed my code around so that it
only schedules one non-blocking exec at a time (Ie i go from open to
free before doing another open operation). This resolves the -34 error
code with the wait_closed but the leak in the other thread we discussed
is still present with this change.

If multiple non-blocking execs can't be sent on the session, might be
helpful to add that info to the man page. If the intent is for multiple
non-blocing execs to occur on a session at one time, the code as is
appears defective.

Hope the extra info helps.

Regards
-steve

> Thanks!
> -steve
>
>
>
>> //Peter
>> _______________________________________________
>> libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
>
>
>
> _______________________________________________
> libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel

_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
Received on 2012-02-26

the libssh2 team