mintty: Ctrl-Q does not work?
Andy Koppe
andy.koppe@gmail.com
Sun Oct 28 06:24:00 GMT 2012
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cygcheck.out
Type: application/octet-stream
Size: 11547 bytes
Desc: not available
URL: <http://cygwin.com/pipermail/cygwin/attachments/20121028/5430660e/attachment.obj>
-------------- next part --------------
--
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
More information about the Cygwin
mailing list