This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: TTY write deadlock

On 5 April 2009 00:03, Christopher Faylor wrote:
> On Sat, Apr 04, 2009 at 03:11:06PM -0700, Josh Stone wrote:
>>I've discovered a deadlock in Cygwin which is pretty easy to
>>reproduce.?? This seems to happen on all of the console windows I can
>>find, except for running in a normal cmd.exe. ÂAll of these are
>>affected though: xterm, rxvt, mintty, puttycyg+cthelper, and putty
>>localhost -> cygwin sshd.
>>To reproduce, run a command that produces a lot of output -- "man -P
>>cat bash" works well. ÂWhile it's thinking about formatting that, just
>>start mashing the keyboard. ÂWhen it starts writing out the manpage
>>while you're still mashing keys, it will lock up (100% of the time for
>>me). ÂYou can kill the (Schr??dinger???s) cat and life will be ok again.
>>I did some debugging and found that the terminal was stuck on
>>acquire_output_mutex in fhandler_pty_master::doecho. ÂThe cat process
>>had fhandler_tty_slave::write in its backtrace, so it was holding the
>>write mutex. ÂThe cat won't release the mutex until its data is read,
>>but the terminal won't read until after it acquires the mutex and
>>finishes doecho.
>>This is on cygwin-1.7.0-45, but I can reproduce it on the 1.5 series
>>too. ÂAnd since it happens on so many terminals and even sshd, I don't
>>think we can say it's the application's fault. ÂI can't reproduce it
>>with a command like "man bash | cat" though, probably because the
>>difference in line buffering makes the race harder to hit.
> I can duplicate this. ÂI'll look into fixing it ASAP.

On 12 April 2009 16:49, Christopher Faylor:
> It took me a while to remember that this is a long standing bug. ÂI
> think it is possible to fix thanks to the changes in Cygwin 1.7 but it
> isn't a trivial fix. ÂI will still poke at this as I have time but
> it may require a minor rewrite of the tty layer to get right.

I just stumbled into this issue while investigating a hang reported
against mintty 0.6-beta1. I found that a single keypress while catting
a large file can trigger this, and like the OP I was able to reproduce
it in all the pty-based terminals. Surprised this doesn't come up more
frequently, but I guess hacking away at the keyboard while output is
going on just isn't something one would normally do.

Anyway, as long as there isn't a fix, is there anything I could do in
mintty to work around this? Would it help to move the writing of
keyboard input to the pty device into its own thread?


Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]