DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 51SClrXe1202061 Authentication-Results: delorie.com; dmarc=pass (p=none dis=none) header.from=cygwin.com Authentication-Results: delorie.com; spf=pass smtp.mailfrom=cygwin.com DKIM-Filter: OpenDKIM Filter v2.11.0 delorie.com 51SClrXe1202061 Authentication-Results: delorie.com; dkim=pass (1024-bit key, unprotected) header.d=cygwin.com header.i=@cygwin.com header.a=rsa-sha256 header.s=default header.b=Z1IzztCA X-Recipient: archive-cygwin AT delorie DOT com DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org CD7F43858C2F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com; s=default; t=1740746872; bh=IVtRPNfnd+im5rXMDvjBLtneOxoKDKauxYMMySUZG6Q=; h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=Z1IzztCA18QLWa1fTG3Vl5naz8Bpy4dw7E6qLiww6gb0bZbozTDOkoFGVfhO9ugXe nl6ZWl7rEjKjxMcQXkA5uBuph5cRf5pO/UlJjIKORfvhGa93f2Y7kYreqKYZPyDvn0 /bgFdkRc4P+zJbB+GAlz2B6gRtFHu3c+GG7jynTc= X-Original-To: cygwin AT cygwin DOT com Delivered-To: cygwin AT cygwin DOT com DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1742B3858C56 Date: Fri, 28 Feb 2025 13:46:49 +0100 To: Rainer Emrich Subject: Re: [CALL FOR TESTING] Cygwin-3.6.0 Message-ID: Mail-Followup-To: Rainer Emrich , cygwin AT cygwin DOT com References:

<4b6dd111-6404-45c0-b839-35e6621be235 AT emrich-ebersheim DOT de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4b6dd111-6404-45c0-b839-35e6621be235@emrich-ebersheim.de> X-BeenThere: cygwin AT cygwin DOT com X-Mailman-Version: 2.1.30 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Corinna Vinschen via Cygwin Reply-To: cygwin AT cygwin DOT com Cc: Corinna Vinschen , cygwin AT cygwin DOT com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com Sender: "Cygwin" Hi Rainer, On Feb 17 20:37, Rainer Emrich via Cygwin wrote: > Am 17.02.2025 um 18:00 schrieb Corinna Vinschen via Cygwin: > > On Feb 17 12:51, Rainer Emrich via Cygwin wrote: > > > I'm facing a strange major issue with scp. The issue exists in all cygwin version later than 3.5.3, > > > including cygwin-3.6.0-0.374.g4dd859d01c22. > > > > > > If I'm copying a large file with scp I get a "connection lost" after a random couple of seconds: > > > > > > scp -v large_file foobar: > > > . > > > . > > > debug1: Sending subsystem: sftp > > > debug1: pledge: fork > > > large_file 10% 71MB 4.3MB/s 02:21 ETA > > > debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 > > > debug1: client_input_channel_req: channel 0 rtype eow AT openssh DOT com reply 0 > > > debug1: channel 0: free: client-session, nchannels 1 > > > Transferred: sent 92266460, received 35436 bytes, in 15.3 seconds > > > Bytes per second: sent 6035219.0, received 2317.9 > > > debug1: Exit status 11 > > > lost connection > > > > In fact, I can reproduce this occassionally back to 3.5.0 and back to > > OpenSSH 9.7p1. We can't easily try this with older Cygwin versions. > > It's getting increasingly hard to build older Cygwin versions due to > > compiler dependencies and missing symbols. > at least for my file size, around 700MB, I can't reproduce this with cygwin > 3.5.3. I noticed this issue for the first time in the autumn last year. > > > What that means in the first place, is that this is neither a regression > > from 3.5.7, nor even from 3.5.1. Obviously I can't prove if this has > > been introduced into 3.5.0, but I'd like to point out that we didn't > > have any noticable change in the socket code for almost 4 years, back > > during 3.3 development. > > > > Fun fact: I can NOT reproduce the problem when using the -O option, > > i. e., when using the old scp protocol. The old protocol isn't > > slower either. > > > > Maybe that's a workaround for you? > > I try this, thanks. I'm debugging this problem on and off for the last couple of days, and even discussing it with one of the upstream OpenSSH maintainers. But it's still a mystery to me. The "lost connection" message does not really point to the cause of the problem, it's just a followup effect: The server receives an EPIPE on the read socket, which in turn results in the clientside ssh to receive an "end-of-write" packet from the server, which in turn results in ssh closing the pipe to scp, which in turn prints the "lost connection" message. The only thing I can say so far is that it appears to be signal related. Fact is, that scp usually runs a SIGALRM triggered progressmeter. If you disable the progressmeter by running scp with the -q option, you can avoid the "lost connection" as well, you don't have to ron scp -O. > > > The strange thing, if I use strace to debug this, the cpoy succeeds: > > > strace -efno strace.log scp -v large_file foobar: > > > > This often points to a timing issue, but beats me where that could be. > > > > > I would try to debug this further, if I had an idea how to do that. > > > > Same here ATM, sorry. > > That's really strange. Yeah, I know. But it's really tricky. All my debugging so far only turned up followup effects, not the actual cause. Sigh. Corinna -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation: https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple