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
