mintty: Ctrl-Q does not work?

mintty: Ctrl-Q does not work?

[Helmut Karlowski]

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?

-- 
Helmut Karlowski

--
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

Re: mintty: Ctrl-Q does not work?

[Thomas Wolff]

On 25.09.2012 12:05, 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?
>
Yes, and it seems to be an issue with cat, not mintty:

cat x           hangs
grep . x        works
cat x | grep .  works
grep . x | cat  hangs for seconds repeatedly even without ^S

Killing the cat process sometimes works (releasing mintty),
sometimes it claims "No such process" although it's in the task table (ps).

------
Thomas

--
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

Re: mintty: Ctrl-Q does not work?

[Ryan Johnson]

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.

Regards,
Ryan

--
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

Re: mintty: Ctrl-Q does not work?

[Andy Koppe]

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

Re: mintty: Ctrl-Q does not work?

[Christopher Faylor]

On Sat, Oct 06, 2012 at 05:48:44AM +0100, Andy Koppe wrote:
>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.

This should work in the latest snapshot.  I added a polling kludge for
1.7.17 while I mull over the best way to handle this.

cgf

--
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

Re: mintty: Ctrl-Q does not work?

[Andy Koppe]

On 13 October 2012 16:38, Christopher Faylor wrote:
> On Sat, Oct 06, 2012 at 05:48:44AM +0100, Andy Koppe wrote:
>>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.
>
> This should work in the latest snapshot.  I added a polling kludge for
> 1.7.17 while I mull over the best way to handle this.

Using snapshot 2012-10-16, I confirmed that Ctrl+S during a long cat
no longer freezes the terminal and that Ctrl+Q

However, I still see the deadlock described above when hitting any
other key that sends something, e.g. just Enter.

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

Re: mintty: Ctrl-Q does not work?

[Corinna Vinschen]

On Oct 19 12:26, Andy Koppe wrote:
> On 13 October 2012 16:38, Christopher Faylor wrote:
> > On Sat, Oct 06, 2012 at 05:48:44AM +0100, Andy Koppe wrote:
> >>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.
> >
> > This should work in the latest snapshot.  I added a polling kludge for
> > 1.7.17 while I mull over the best way to handle this.
> 
> Using snapshot 2012-10-16, I confirmed that Ctrl+S during a long cat
> no longer freezes the terminal and that Ctrl+Q
> 
> However, I still see the deadlock described above when hitting any
> other key that sends something, e.g. just Enter.

Too bad.  Are you sure?  I tried really hard to get a deadlock and could
not reproduce it anymore under W7.  My Enter key is still on paracetamol.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
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

Re: mintty: Ctrl-Q does not work?

[Christopher Faylor]

On Fri, Oct 19, 2012 at 02:17:29PM +0200, Corinna Vinschen wrote:
>On Oct 19 12:26, Andy Koppe wrote:
>> On 13 October 2012 16:38, Christopher Faylor wrote:
>> > On Sat, Oct 06, 2012 at 05:48:44AM +0100, Andy Koppe wrote:
>> >>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.
>> >
>> > This should work in the latest snapshot.  I added a polling kludge for
>> > 1.7.17 while I mull over the best way to handle this.
>> 
>> Using snapshot 2012-10-16, I confirmed that Ctrl+S during a long cat
>> no longer freezes the terminal and that Ctrl+Q
>> 
>> However, I still see the deadlock described above when hitting any
>> other key that sends something, e.g. just Enter.
>
>Too bad.  Are you sure?  I tried really hard to get a deadlock and could
>not reproduce it anymore under W7.  My Enter key is still on paracetamol.

I can't duplicate it either.  I do notice that Cygwin doesn't work like
UNIX in that characters are still echoed after CTRL-S is hit.  That's
wrong but it looks like making it right will require major surgery.

Must.  Resist.  YA.  Pty.  Rewrite.

cgf

--
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

Re: mintty: Ctrl-Q does not work?

[Andy Koppe]

On 19 October 2012 16:00, Christopher Faylor wrote:
> On Fri, Oct 19, 2012 at 02:17:29PM +0200, Corinna Vinschen wrote:
>>On Oct 19 12:26, Andy Koppe wrote:
>>> On 13 October 2012 16:38, Christopher Faylor wrote:
>>> > On Sat, Oct 06, 2012 at 05:48:44AM +0100, Andy Koppe wrote:
>>> >>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.
>>> >
>>> > This should work in the latest snapshot.  I added a polling kludge for
>>> > 1.7.17 while I mull over the best way to handle this.
>>>
>>> Using snapshot 2012-10-16, I confirmed that Ctrl+S during a long cat
>>> no longer freezes the terminal and that Ctrl+Q
>>>
>>> However, I still see the deadlock described above when hitting any
>>> other key that sends something, e.g. just Enter.
>>
>>Too bad.  Are you sure?  I tried really hard to get a deadlock and could
>>not reproduce it anymore under W7.  My Enter key is still on paracetamol.
>
> I can't duplicate it either.

Sorry I didn't get round to have another look at this before the 1.7.17 release.

I found that it's the CYGWIN=pipe_byte option that makes the
difference. In 1.7.16, the deadlock occurs with and without that
option. It 1.7.17, it only occurs with pipe_byte enabled.

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

Re: mintty: Ctrl-Q does not work?

[Christopher Faylor]

On Sun, Oct 21, 2012 at 05:38:11AM +0100, Andy Koppe wrote:
>On 19 October 2012 16:00, Christopher Faylor wrote:
>> On Fri, Oct 19, 2012 at 02:17:29PM +0200, Corinna Vinschen wrote:
>>>On Oct 19 12:26, Andy Koppe wrote:
>>>> On 13 October 2012 16:38, Christopher Faylor wrote:
>>>> > On Sat, Oct 06, 2012 at 05:48:44AM +0100, Andy Koppe wrote:
>>>> >>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.
>>>> >
>>>> > This should work in the latest snapshot.  I added a polling kludge for
>>>> > 1.7.17 while I mull over the best way to handle this.
>>>>
>>>> Using snapshot 2012-10-16, I confirmed that Ctrl+S during a long cat
>>>> no longer freezes the terminal and that Ctrl+Q
>>>>
>>>> However, I still see the deadlock described above when hitting any
>>>> other key that sends something, e.g. just Enter.
>>>
>>>Too bad.  Are you sure?  I tried really hard to get a deadlock and could
>>>not reproduce it anymore under W7.  My Enter key is still on paracetamol.
>>
>> I can't duplicate it either.
>
>Sorry I didn't get round to have another look at this before the 1.7.17 release.
>
>I found that it's the CYGWIN=pipe_byte option that makes the
>difference. In 1.7.16, the deadlock occurs with and without that
>option. It 1.7.17, it only occurs with pipe_byte enabled.

Still can't duplicate it.  pipe_byte was designed to be used only with
anonymous pipes and not with ptys so it shouldn't have any effect on
pty handling.

cgf

--
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

Re: mintty: Ctrl-Q does not work?

[Andy Koppe]

[-- Attachment #1: Type: text/plain, Size: 4378 bytes --]

On 21 October 2012 06:44, Christopher Faylor wrote:
> On Sun, Oct 21, 2012 at 05:38:11AM +0100, Andy Koppe wrote:
>>On 19 October 2012 16:00, Christopher Faylor wrote:
>>> On Fri, Oct 19, 2012 at 02:17:29PM +0200, Corinna Vinschen wrote:
>>>>On Oct 19 12:26, Andy Koppe wrote:
>>>>> On 13 October 2012 16:38, Christopher Faylor wrote:
>>>>> > On Sat, Oct 06, 2012 at 05:48:44AM +0100, Andy Koppe wrote:
>>>>> >>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.
>>>>> >
>>>>> > This should work in the latest snapshot.  I added a polling kludge for
>>>>> > 1.7.17 while I mull over the best way to handle this.
>>>>>
>>>>> Using snapshot 2012-10-16, I confirmed that Ctrl+S during a long cat
>>>>> no longer freezes the terminal and that Ctrl+Q
>>>>>
>>>>> However, I still see the deadlock described above when hitting any
>>>>> other key that sends something, e.g. just Enter.
>>>>
>>>>Too bad.  Are you sure?  I tried really hard to get a deadlock and could
>>>>not reproduce it anymore under W7.  My Enter key is still on paracetamol.
>>>
>>> I can't duplicate it either.
>>
>>Sorry I didn't get round to have another look at this before the 1.7.17 release.
>>
>>I found that it's the CYGWIN=pipe_byte option that makes the
>>difference. In 1.7.16, the deadlock occurs with and without that
>>option. It 1.7.17, it only occurs with pipe_byte enabled.
>
> Still can't duplicate it.  pipe_byte was designed to be used only with
> anonymous pipes and not with ptys so it shouldn't have any effect on
> pty handling.

You're right, on further tests, pipe_byte doesn't matter. Not sure
what happened; a case of seeing what one expects to see, probably.
Sorry.

However, I can still reproduce the issue (without pipe_byte), and I
did a fresh Cygwin install into the default location to try to
minimise variables. Cygcheck output attached.

Here's what I did:
- Make sure no Cygwin processes are running.
- Open the "Cygwin Terminal" desktop shortcut
- cd to the winsup/cygwin directory in a pre-existing checkout of the
Cygwin sources
- cat *.cc
- Hit Enter once: output stops, soon after the terminal window goes
grey and "(Not Responding)" is added to the window title. (I'd also
had cases where I had to hit Enter repeatedly to make this happen.)
- Open another terminal.
- ps
> O     224    3792     224       2884  pty0    1004 06:14:33 /usr/bin/cat
> O    1544       1    1544       1544  ?       1004 06:08:36 /usr/bin/mintty
- kill 224: first window comes back to life, with output ending like this:
> ntdev, S_IFBLK, true},
>  {"/dev/sdcf4", BRACK(FH_SDCF | 4), "\\Device\\Harddisk83\\Partition4", exists_ntdev,
>S_IFBLK, true},
>  {"/dev/sdcf5", B
>Terminated

Please let me know if I can provide anything else.

Regards,
Andy

[-- Attachment #2: cygcheck.out --]
[-- Type: application/octet-stream, Size: 11547 bytes --]


Cygwin Configuration Diagnostics
Current System Time: Sun Oct 28 06:58:03 2012

Windows 7 Professional N Ver 6.1 Build 7601 Service Pack 1

Running under WOW64 on AMD64

Path:	C:\cygwin\usr\local\bin
	C:\cygwin\bin
	C:\Program Files (x86)\PC Connectivity Solution
	C:\Windows\system32
	C:\Windows
	C:\Windows\System32\Wbem
	C:\Windows\System32\WindowsPowerShell\v1.0

Output from C:\cygwin\bin\id.exe
UID: 1004(Andy) GID: 513(None)
513(None)       545(Users)      1000(HomeUsers)

SysDir: C:\Windows\system32
WinDir: C:\Windows

USER = 'Andy'
PWD = '/home/Andy'
HOME = '/home/Andy'

HOMEPATH = '\Users\Andy'
MANPATH = '/usr/local/man:/usr/share/man:/usr/man:'
APPDATA = 'C:\Users\Andy\AppData\Roaming'
ProgramW6432 = 'C:\Program Files'
HOSTNAME = 'Talisker'
SHELL = '/bin/bash'
TERM = 'xterm'
PROCESSOR_IDENTIFIER = 'AMD64 Family 15 Model 72 Stepping 2, AuthenticAMD'
WINDIR = 'C:\Windows'
PUBLIC = 'C:\Users\Public'
OLDPWD = '/cygdrive/c/Users/Andy/Desktop'
USERDOMAIN = 'TALISKER'
CommonProgramFiles(x86) = 'C:\Program Files (x86)\Common Files'
OS = 'Windows_NT'
ALLUSERSPROFILE = 'C:\ProgramData'
VBOX_INSTALL_PATH = 'C:\Program Files\Oracle\VirtualBox\'
!:: = '::\'
temp = 'C:\Users\Andy\AppData\Local\Temp'
COMMONPROGRAMFILES = 'C:\Program Files (x86)\Common Files'
TMP = '/tmp'
USERNAME = 'Andy'
PROCESSOR_LEVEL = '15'
ProgramFiles(x86) = 'C:\Program Files (x86)'
PSModulePath = 'C:\Windows\system32\WindowsPowerShell\v1.0\Modules\'
FP_NO_HOST_CHECK = 'NO'
SYSTEMDRIVE = 'C:'
PROCESSOR_ARCHITEW6432 = 'AMD64'
LANG = 'en_US.UTF-8'
USERPROFILE = 'C:\Users\Andy'
TZ = 'Europe/London'
PS1 = '\[\e]0;\w\a\]\n\[\e[32m\]\u@\h \[\e[33m\]\w\[\e[0m\]\n\$ '
LOGONSERVER = '\\TALISKER'
CommonProgramW6432 = 'C:\Program Files\Common Files'
PROCESSOR_ARCHITECTURE = 'x86'
LOCALAPPDATA = 'C:\Users\Andy\AppData\Local'
ProgramData = 'C:\ProgramData'
SHLVL = '1'
PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC'
HOMEDRIVE = 'C:'
COMSPEC = 'C:\Windows\system32\cmd.exe'
SYSTEMROOT = 'C:\Windows'
PRINTER = 'HP LaserJet P1006'
PROCESSOR_REVISION = '4802'
INFOPATH = '/usr/local/info:/usr/share/info:/usr/info:'
PROGRAMFILES = 'C:\Program Files (x86)'
NUMBER_OF_PROCESSORS = '2'
asl.log = 'Destination=file'
SESSIONNAME = 'Console'
COMPUTERNAME = 'TALISKER'
_ = '/usr/bin/cygcheck'

HKEY_CURRENT_USER\Software\Cygwin
HKEY_CURRENT_USER\Software\Cygwin\Installations
  (default) = '\??\C:\cygwin'
HKEY_CURRENT_USER\Software\Cygwin\Program Options
HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin
HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\Installations
  (default) = '\??\C:'
  26a8341cd07d8d52 = '\??\C:\cyg179'
  c5e39b7a9d22bafb = '\??\C:\cygwin'
HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\Program Options
HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin\setup
  (default) = 'C:\cygwin'

obcaseinsensitive set to 1

Cygwin installations found in the registry:
  System: Key: a46ac466ed629d62 Path: C:
  System: Key: 26a8341cd07d8d52 Path: C:\cyg179
  System: Key: c5e39b7a9d22bafb Path: C:\cygwin
  User:   Key: c5e39b7a9d22bafb Path: C:\cygwin

c:  hd  NTFS     32763Mb  97% CP CS UN PA FC     Seven
d:  hd  NTFS    119859Mb  68% CP CS UN PA FC     Vista

C:\cygwin        /          system  binary,auto
C:\cygwin\bin    /usr/bin   system  binary,auto
C:\cygwin\lib    /usr/lib   system  binary,auto
cygdrive prefix  /cygdrive  user    binary,auto

Found: C:\cygwin\bin\awk
 -> C:\cygwin\bin\gawk.exe
Found: C:\cygwin\bin\bash.exe
Found: C:\cygwin\bin\cat.exe
Found: C:\cygwin\bin\cp.exe
Not Found: cpp (good!)
Not Found: crontab
Found: C:\cygwin\bin\find.exe
Found: C:\Windows\system32\find.exe
Warning: C:\cygwin\bin\find.exe hides C:\Windows\system32\find.exe
Not Found: gcc
Not Found: gdb
Found: C:\cygwin\bin\grep.exe
Found: C:\cygwin\bin\kill.exe
Not Found: ld
Found: C:\cygwin\bin\ls.exe
Not Found: make
Found: C:\cygwin\bin\mv.exe
Not Found: patch
Not Found: perl
Found: C:\cygwin\bin\rm.exe
Found: C:\cygwin\bin\sed.exe
Not Found: ssh
Found: C:\cygwin\bin\sh.exe
Found: C:\cygwin\bin\tar.exe
Found: C:\cygwin\bin\test.exe
Not Found: vi
Not Found: vim

   14k 2012/05/04 C:\cygwin\bin\cygattr-1.dll - os=4.0 img=1.0 sys=4.0
                  "cygattr-1.dll" v0.0 ts=2012/5/4 12:35
   62k 2011/05/21 C:\cygwin\bin\cygbz2-1.dll - os=4.0 img=1.0 sys=4.0
                  "cygbz2-1.dll" v0.0 ts=2011/5/21 20:16
   43k 2010/01/02 C:\cygwin\bin\cygform-10.dll - os=4.0 img=1.0 sys=4.0
                  "cygform-10.dll" v0.0 ts=2010/1/2 14:49
   47k 2010/01/02 C:\cygwin\bin\cygformw-10.dll - os=4.0 img=1.0 sys=4.0
                  "cygformw-10.dll" v0.0 ts=2010/1/2 17:31
   79k 2011/10/26 C:\cygwin\bin\cyggcc_s-1.dll - os=4.0 img=1.0 sys=4.0
                  "cyggcc_s-1.dll" v0.0 ts=2011/10/23 14:15
  317k 2011/07/31 C:\cygwin\bin\cyggmp-3.dll - os=4.0 img=1.0 sys=4.0
                  "cyggmp-3.dll" v0.0 ts=2011/7/31 6:14
   25k 2012/05/04 C:\cygwin\bin\cyghistory7.dll - os=4.0 img=1.0 sys=4.0
                  "cyghistory7.dll" v0.0 ts=2012/5/4 22:07
  358k 2012/04/14 C:\cygwin\bin\cygicons-0.dll - os=4.0 img=1.4 sys=4.0
                  "cygicons-0.dll" v0.0 ts=2012/4/14 2:48
  985k 2011/10/16 C:\cygwin\bin\cygiconv-2.dll - os=4.0 img=1.0 sys=4.0
                  "cygiconv-2.dll" v0.0 ts=2011/10/16 18:01
   35k 2011/10/16 C:\cygwin\bin\cygintl-8.dll - os=4.0 img=1.0 sys=4.0
                  "cygintl-8.dll" v0.0 ts=2011/10/16 6:38
    6k 2012/10/19 C:\cygwin\bin\cyglsa.dll - os=4.0 img=1.0 sys=4.0
                  "cyglsa.dll" v0.0 ts=2012/10/19 13:40
    9k 2012/10/19 C:\cygwin\bin\cyglsa64.dll - os=5.2 img=0.0 sys=5.2
  123k 2011/05/19 C:\cygwin\bin\cyglzma-5.dll - os=4.0 img=1.0 sys=4.0
                  "cyglzma-5.dll" v0.0 ts=2011/5/19 3:41
   94k 2012/04/22 C:\cygwin\bin\cygmagic-1.dll - os=4.0 img=1.0 sys=4.0
                  "cygmagic-1.dll" v0.0 ts=2012/4/22 19:09
   25k 2010/01/02 C:\cygwin\bin\cygmenu-10.dll - os=4.0 img=1.0 sys=4.0
                  "cygmenu-10.dll" v0.0 ts=2010/1/2 14:48
   25k 2010/01/02 C:\cygwin\bin\cygmenuw-10.dll - os=4.0 img=1.0 sys=4.0
                  "cygmenuw-10.dll" v0.0 ts=2010/1/2 17:30
  213k 2011/07/31 C:\cygwin\bin\cygmp-3.dll - os=4.0 img=1.0 sys=4.0
                  "cygmp-3.dll" v0.0 ts=2011/7/31 6:12
   63k 2010/01/02 C:\cygwin\bin\cygncurses++-10.dll - os=4.0 img=1.0 sys=4.0
                  "cygncurses++-10.dll" v0.0 ts=2010/1/2 15:00
   63k 2010/01/02 C:\cygwin\bin\cygncurses++w-10.dll - os=4.0 img=1.0 sys=4.0
                  "cygncurses++w-10.dll" v0.0 ts=2010/1/2 17:41
  195k 2010/01/02 C:\cygwin\bin\cygncurses-10.dll - os=4.0 img=1.0 sys=4.0
                  "cygncurses-10.dll" v0.0 ts=2010/1/2 14:45
  244k 2010/01/02 C:\cygwin\bin\cygncursesw-10.dll - os=4.0 img=1.0 sys=4.0
                  "cygncursesw-10.dll" v0.0 ts=2010/1/2 17:28
   13k 2010/01/02 C:\cygwin\bin\cygpanel-10.dll - os=4.0 img=1.0 sys=4.0
                  "cygpanel-10.dll" v0.0 ts=2010/1/2 14:47
   13k 2010/01/02 C:\cygwin\bin\cygpanelw-10.dll - os=4.0 img=1.0 sys=4.0
                  "cygpanelw-10.dll" v0.0 ts=2010/1/2 16:30
  255k 2012/02/10 C:\cygwin\bin\cygpcre-0.dll - os=4.0 img=1.0 sys=4.0
                  "cygpcre-0.dll" v0.0 ts=2012/2/10 10:24
   22k 2002/06/09 C:\cygwin\bin\cygpopt-0.dll - os=4.0 img=1.0 sys=4.0
                  "cygpopt-0.dll" v0.0 ts=2002/6/9 6:45
  162k 2012/05/04 C:\cygwin\bin\cygreadline7.dll - os=4.0 img=1.0 sys=4.0
                  "cygreadline7.dll" v0.0 ts=2012/5/4 22:07
    8k 2011/05/05 C:\cygwin\bin\cygsigsegv-2.dll - os=4.0 img=1.0 sys=4.0
                  "cygsigsegv-2.dll" v0.0 ts=2011/5/5 8:33
  780k 2011/10/26 C:\cygwin\bin\cygstdc++-6.dll - os=4.0 img=1.0 sys=4.0
                  "cygstdc++-6.dll" v0.0 ts=2011/10/23 14:58
   48k 2010/01/02 C:\cygwin\bin\cygtic-10.dll - os=4.0 img=1.0 sys=4.0
                  "cygtic-10.dll" v0.0 ts=2010/1/2 14:45
   48k 2010/01/02 C:\cygwin\bin\cygticw-10.dll - os=4.0 img=1.0 sys=4.0
                  "cygticw-10.dll" v0.0 ts=2010/1/2 17:28
   71k 2012/05/13 C:\cygwin\bin\cygz.dll - os=4.0 img=1.0 sys=4.0
                  "cygz.dll" v0.0 ts=2012/5/13 5:11
 2791k 2012/10/19 C:\cygwin\bin\cygwin1.dll - os=4.0 img=1.0 sys=4.0
                  "cygwin1.dll" v0.0 ts=2012/10/19 13:39
    Cygwin DLL version info:
        DLL version: 1.7.17
        DLL epoch: 19
        DLL old termios: 5
        DLL malloc env: 28
        Cygwin conv: 181
        API major: 0
        API minor: 262
        Shared data: 5
        DLL identifier: cygwin1
        Mount registry: 3
        Cygwin registry name: Cygwin
        Program options name: Program Options
        Installations name: Installations
        Cygdrive default prefix: 
        Build date: 
        Shared id: cygwin1S5


Can't find the cygrunsrv utility, skipping services check.


Cygwin Package Information
Last downloaded files to: C:\tmp
Last downloaded files from: http://ftp.inf.tu-dresden.de/software/windows/cygwin32/

Package              Version              Status
_autorebase          000149-1             OK
_update-info-dir     01084-1              OK
alternatives         1.3.30c-10           OK
apngopt              1.1-1                OK
base-cygwin          3.1-1                OK
base-files           4.1-1                OK
bash                 4.1.10-4             OK
bzip2                1.0.6-2              OK
coreutils            8.15-1               OK
cygutils             1.4.10-2             OK
cygwin               1.7.17-1             OK
cygwin-doc           1.7-1                OK
dash                 0.5.7-1              OK
diffutils            3.2-1                OK
dos2unix             6.0.2-1              OK
editrights           1.01-2               OK
file                 5.11-1               OK
findutils            4.5.9-2              OK
gawk                 4.0.1-1              OK
gettext              0.18.1.1-2           OK
grep                 2.6.3-1              OK
groff                1.21-2               OK
gzip                 1.4-1                OK
ipc-utils            1.0-1                OK
less                 444-1                OK
libattr1             2.4.46-1             OK
libbz2_1             1.0.6-2              OK
libgcc1              4.5.3-3              OK
libgmp3              4.3.2-1              OK
libiconv2            1.14-2               OK
libintl8             0.18.1.1-2           OK
liblzma5             5.0.2_20110517-1     OK
libncurses10         5.7-18               OK
libncursesw10        5.7-18               OK
libpcre0             8.21-2               OK
libpopt0             1.6.4-4              OK
libreadline7         6.1.2-3              OK
libsigsegv2          2.10-1               OK
libstdc++6           4.5.3-3              OK
login                1.10-10              OK
man                  1.6g-1               OK
mintty               1.1.2-1              OK
rebase               4.3.0-1              OK
run                  1.1.13-1             OK
sed                  4.2.1-2              OK
tar                  1.26-1               OK
terminfo             5.7_20091114-14      OK
texinfo              4.13-4               OK
tzcode               2012e-1              OK
which                2.20-2               OK
xz                   5.0.2_20110517-1     OK
zlib0                1.2.7-1              OK
Use -h to see help about each section

[-- Attachment #3: Type: text/plain, Size: 218 bytes --]

--
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

Re: mintty: Ctrl-Q does not work?

[Helmut Karlowski]

Andy Koppe, 28.10.2012 07:24:04:

> However, I can still reproduce the issue (without pipe_byte), and I
> did a fresh Cygwin install into the default location to try to
> minimise variables. Cygcheck output attached.

I just installed the latest cygwin-release. Ctrl-S,Ctrl-Q works as  
expected, but e.g. Enter stops output and freezes the terminal like before  
(need to kill -9 the involved process). Why is there any reaction on Enter  
at all?

-- 
Helmut Karlowski

--
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

Re: mintty: Ctrl-Q does not work?

[Christopher Faylor]

On Sun, Oct 28, 2012 at 06:17:27PM +0100, Helmut Karlowski wrote:
>Andy Koppe, 28.10.2012 07:24:04:
>
>> However, I can still reproduce the issue (without pipe_byte), and I
>> did a fresh Cygwin install into the default location to try to
>> minimise variables. Cygcheck output attached.
>
>I just installed the latest cygwin-release. Ctrl-S,Ctrl-Q works as  
>expected, but e.g. Enter stops output and freezes the terminal like before  
>(need to kill -9 the involved process). Why is there any reaction on Enter  
>at all?

It's what we in the software industry call "a bug".

--
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

RE: mintty: Ctrl-Q does not work?

[Charles Stepp]

> Andy Koppe, 28.10.2012 07:24:04:
>
> > However, I can still reproduce the issue (without pipe_byte), and I
> > did a fresh Cygwin install into the default location to try to
> > minimise variables. Cygcheck output attached.
>
> I just installed the latest cygwin-release. Ctrl-S,Ctrl-Q works as expected, but e.g. Enter stops output and freezes the terminal like before (need to kill -9 the involved process). Why is there any reaction on Enter at all?
>
> --
> Helmut Karlowski

The stty ixany setting determines whether any key or the start key (Ctl-Q) resumes output after a stop key (Ctl-S).

stty  ixany enables resuming output with any key.
stty -ixany sets it such that only the start key (Ctl-Q) resumes output.

--
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

Re: mintty: Ctrl-Q does not work?

[Christopher Faylor]

On Mon, Oct 29, 2012 at 12:49:24PM +0000, Charles Stepp wrote:
>> Andy Koppe, 28.10.2012 07:24:04:
>>
>> > However, I can still reproduce the issue (without pipe_byte), and I
>> > did a fresh Cygwin install into the default location to try to
>> > minimise variables. Cygcheck output attached.
>>
>>I just installed the latest cygwin-release.  Ctrl-S,Ctrl-Q works as
>>expected, but e.g.  Enter stops output and freezes the terminal like
>>before (need to kill -9 the involved process).  Why is there any
>>reaction on Enter at all?
>
>The stty ixany setting determines whether any key or the start key
>(Ctl-Q) resumes output after a stop key (Ctl-S).
>
>stty  ixany enables resuming output with any key.
>stty -ixany sets it such that only the start key (Ctl-Q) resumes output.

There was no "Ctl-S" in the above description.

--
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