This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: scp exits often with -1


Hi Bob and Pierre

thanks for your analysis so far.

Bob Byrnes wrote on Friday, November 19, 2004 5:49 PM:

> I spent a little time looking at these straces and scp -v
> output. I still don't understand what's going on, but it
> seems to be unrelated to the recent pipe changes.  I say that
> because those changes only affected select for writes on
> pipes, and the problem seems to be on the read side. It looks
> like scp and ssh are sending only single bytes across the
> pipe when the failure occurs, so the pipe is almost empty,
> and (correctly) always selects writable anyway.  Something is
> making the pipe disappear, causing PeekNamedPipe to fail for
> the ssh process in the select for read on pipes code (which
> has not been changed).
> 
> Either something is going catastrophically wrong with the
> pipe at a very low level, or the scp process is closing it in
> a way that ssh does not expect.  So far, I can't tell which
> is happening, but I did note one significant difference in
> the scp -v output: only the "good" invocation has ...
> 
> debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
> 
> An examination of the ssh sources to see what this means
> might be enlightening, but I don't have time to do that right now.

This debug output is generated calling function "client_input_channel_req" in clientloop.c. This means, that the function is not called in the "bad" case. This method is only referenced in the same file in function "client_init_dispatch_20" in the call "dispatch_set(SSH2_MSG_CHANNEL_REQUEST, &client_input_channel_req);". This constant is only used in serverloop.c also to initialize a dispatcher function and in channels.c in the function "channel_request_start" calling "packet_start(SSH2_MSG_CHANNEL_REQUEST);".

I have to admin, that this does still not really help yet, since it does not give any hint, why no packet with "exit-status" was received at all in the bad case.

Looking into function "dispatch_run" of dispatcher.c I can only guess, that for some reason the call to "packet_read_poll_seqnr" returns "SSH_MSG_NONE".

As Pierre already stated, the trace just has this difference of 120 vs. 64 read bytes in line 4538 and the following call for the debug output. :(

- Jörg

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]