DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 57U3CUsa1736901 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 57U3CUsa1736901 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=x0PALR/6 X-Recipient: archive-cygwin AT delorie DOT com DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 783A43858410 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com; s=default; t=1756523548; bh=Ntr62pdl6JJPKBtJH50XCECGsCkZSg23LgkxkaF9Rb8=; h=Date:To:Subject:In-Reply-To:References:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=x0PALR/6Kh3kDU5MnMnwtRGE6EEtr6eCUOG0cJk2avQC07DArA43ROOeBoeQBER/Z Ou9RfUNpNZbHjkO3VUDmkhHr6i68wjAvDJtHmOI6jmavJgh1opuTPZRr1TacliODVt 4RPaRgEKBqDFpmvROYNXGrBmk/8ilqr6tFcItFMg= X-Original-To: cygwin AT cygwin DOT com Delivered-To: cygwin AT cygwin DOT com DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A3486385841F ARC-Filter: OpenARC Filter v1.0.0 sourceware.org A3486385841F ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1756523475; cv=none; b=f1IpJqV29HDPdsoviwvuf9+yXfcKMCcK2vAHA8immXvA1YiT1fiB4jQ2/ibsIw0gb/8DeqFrbliHMKI3KH8PFwueX6ILxeqnGMvHfosfzA9QhwNge7qjK5zZnlYx+aArs/zH6QOdxGSKkIirpGWtv8Dceow8j7iUvxlKwkhT1B4= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1756523475; c=relaxed/simple; bh=RLPKnlH1fET180iJ36SEwDH24hFFcdr5jmK8n98BJCE=; h=Date:From:To:Subject:Message-Id:Mime-Version:DKIM-Signature; b=sNh8c/LwN0rLJFscC7DuOqnhd7Pa8z3TUXoHvny8FtIHynxMGJ1lJZJxBAnd7fsA+jfEbvVARX8EKWr2sdvRlFe+mJqS5DXysZwUjfKDRDPvmEJn7cVqXtccRsaFdxMcuh6TLRS8aeH/VCGHBMbsc507LeNzdbHltt4c7bfJxlo= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A3486385841F Date: Sat, 30 Aug 2025 12:11:11 +0900 To: cygwin AT cygwin DOT com Subject: Re: pty read loop losing data in wsl context Message-Id: <20250830121111.f6eda5bcc5ff659d43a635f3@nifty.ne.jp> In-Reply-To: <1b1e8e7f-0ee9-41b8-931f-202af6704c4d@towo.net> References: <1b1e8e7f-0ee9-41b8-931f-202af6704c4d AT towo DOT net> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.30; i686-pc-mingw32) Mime-Version: 1.0 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: Takashi Yano via Cygwin Reply-To: Takashi Yano Content-Type: text/plain; charset="utf-8" Errors-To: cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com Sender: "Cygwin" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by delorie.com id 57U3CUsa1736901 On Thu, 28 Aug 2025 05:36:06 +0200 Thomas Wolff wrote: > When running wsl.exe from mintty, typing ^O corrupts terminal display. > This was reported in > https://github.com/mintty/mintty/issues/1332 > and I later reported it towards Windows conpty > https://github.com/microsoft/terminal/issues/19285 > but conpty is unlikely the cause, as testing suggests. > > Test case, in mintty: > wsl > ls -1 /bin > ^O # enter the control character > ls -1 /bin # repeat > > The same happens in xterm and some other terminals, but not all. > > Mintty uses a loop to read terminal output from the pty and fill its buffer: >         do { >           int ret = read(pty_fd, buf + len, sizeof buf - len); >           if (ret > 0) >             len += ret; >           else >             break; >         } while (len < sizeof buf); > Tracing the loop shows that, while running wsl, after having entered ^O, > every subsequent read returns -1. > Taking out the loop (by patching it, or currently by using option Baud > with some high value) fixes the problem. > I suspect some very obscure interworking problem between wsl/conpty and > cygwin pty handling. As noted in the latter issue, it does not happen > with terminals running remotely, so the suspicion goes more to the > cygwin side. > What’s the role of ^O in this puzzle? Does it trigger something in cygwin? > Is there anything peculiar that would cause pty chunks not be recognised > and then skipped in such a loop? Thanks for the report. I fixed the Ctrl^O (FLUSHO) handling. Please try cygwin-3.7.0-dev-286-g7b5fb35e. -- Takashi Yano -- 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