X-Recipient:	archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status:	No, hits=-5.1 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,TW_CG
X-Spam-Check-By:	sourceware.org
MIME-Version:	1.0
In-Reply-To:	<5061B263.4090704@cs.utoronto.ca>
References:	<op DOT wk6rn9deofd6j1 AT nebbiolo> <5061B263 DOT 4090704 AT cs DOT utoronto DOT ca>
Date:	Sat, 6 Oct 2012 05:48:44 +0100
Message-ID:	<CAHWeT-Z-fRp_TzR4uf_8mAB3_usfBHGD-zLwej16Fxj3fG2o3w@mail.gmail.com>
Subject:	Re: mintty: Ctrl-Q does not work?
From:	Andy Koppe <andy DOT koppe AT gmail DOT com>
To:	cygwin AT cygwin DOT com
X-IsSubscribed:	yes
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Unsubscribe:	<mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com

On 25 September 2012 14:32, Ryan Johnson wrote:
> On 25/09/2012 6:05 AM, Helmut Karlowski wrote:
>>
>> I type
>>
>> cat [some long ascii-file]
>>
>> then Ctrl-S (output stops), then Ctrl-Q (terminal hangs, can only be
>> terminated by closing the window).
>>
>> Using minty 1.1.2 and  1.7.16(0.262/5/3) 2012-07-20 22:55 i686 Cygwin
>>
>> Can anybody reproduce this?
>>
> Confirmed with mintty 1.1.1 and the same version of cygwin (w7-64). FWIW,
> doing it with `find .' rather than `cat' works fine.

The issue isn't specific to any of mintty, cat or Ctrl+S; for example,
I've managed to reproduce it with xterm, hexdump, and just hitting
Enter. Any other key that sends a keycode will do too. Ctrl+Q isn't
needed for the freeze to happen. In xterm I've even managed it with
find, by hitting Enter repeatedly.

If you then look at the situation in ps, you'll see something like this:

O    3396       1    3396       1472  ?       1004 05:11:07 /usr/bin/xterm
O    3528    4460    3528        528  pty3    1004 05:25:01 /usr/bin/cat

The interesting bit there is the two 'O's in the first column, which
means both processes are waiting to output. I think what's happening
is that both of them are trying to write to their side of the
underlying pty device, but that those writes are blocking until data
is read from the other side of the pty. Result: deadlock. If the cat
is killed (possibly with -9, because of its nine lives), the terminal
happily continues on its way.

So why doesn't this happen more often? Not sure. The speed difference
between the client process output and the terminal seems to play a
role here. I can only guess that the issue occurs if a buffer in the
pty's slave->master pipe overflows and something is written to the
master->slave pipe at the same time (which is unbuffered?).

I don't understand the pty implementation enough to verify any of
that, so cgf would need to comment further. Note besides: I couldn't
make this deadlock happen on Ubuntu.

Andy

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

- Raw text -