Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: scp exits often with -1 Date: Mon, 22 Nov 2004 11:29:02 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: From: =?iso-8859-1?Q?J=F6rg_Schaible?= To: X-IsSubscribed: yes Reply-To: cygwin AT cygwin DOT com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id iAMATWu6028405 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/