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..
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