search

muhhiminminmin / mintty

Automatically exported from code.google.com/p/mintty
GNU General Public License v3.0
0 stars 0 forks source link

Detached screens created through mintty causes sh to hang #390

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
What steps will reproduce the problem?
1. Download fresh install of Cygwin
2. Use provided mintty (or downloaded latest stable)
3. Create a new detached screen: 'screen -S name -d -m'
4. Attempt to attach to screen: 'screen -S name -x'
5. (hang) -- sh.exe hanged on start, not attach, I believe
6. Killing sh.exe from task manager stops hang
7. Despite returning to shell prompt, key presses are no longer being sent to 
the terminal. Hitting 'return' will scroll but no letters appear.

What is the expected output? What do you see instead?
Attempting to attach to the screen should attach not hang.

What versions of mintty, Cygwin/MSYS, and Windows are you using?
Latest 1.7 Cygwin and mintty from a fresh download.

Please provide any additional information below.
Screen does NOT hang when is is created by calling the first command through 
cygwin started by cygwin.bat (commands typed through Windows terminal 'cmd.exe' 
instead of mintty) and then attempting to attach through mintty with the second 
command.

This suggests that sh is halting when the screen is first created through 
mintty --not during the attach.

This is a big deal. :(

Original issue reported on code.google.com by dvug...@gmail.com on 10 Jun 2013 at 7:14

GoogleCodeExporter commented 8 years ago 
Workaround is to use:

'cygstart --hide screen -S mako -d -m'

This starts the screen process from outside of mintty. I can then attach fine, 
as the shell did not hang.

Original comment by dvug...@gmail.com on 10 Jun 2013 at 7:26

GoogleCodeExporter commented 8 years ago 
There've been various issues with pseudo terminal (pty) layer in the Cygwin 
1.7.19 release, which apparently haven't been fully addressed in 1.7.20. Mintty 
is based on that pty layer, along with other terminals such as rxvt or xterm, 
whereas the Windows console window you get through cygstart is not.

Can you try downgrading to 1.7.18? Rerun setup.exe, click through to the 
package selection screen, find the 'cygwin' package, repeatedly click on its 
'New' column until you get 1.7.18-1, click through the remaining screens. You 
could also try the latest snapshot from http://cygwin.com/snapshots.

Original comment by andy.koppe on 10 Jun 2013 at 7:44

GoogleCodeExporter commented 8 years ago 
It still hangs with 1.7.18 using the same steps.

Original comment by dvug...@gmail.com on 10 Jun 2013 at 8:24

GoogleCodeExporter commented 8 years ago 
Tried again with a backup of cygwin1.dll from 1.7.15, 1.7.7, and it still locks 
up in the same way.

Original comment by dvug...@gmail.com on 10 Jun 2013 at 8:30

GoogleCodeExporter commented 8 years ago 
Same problem in the latest 1.7.20 snapshot.

Original comment by dvug...@gmail.com on 10 Jun 2013 at 8:52

GoogleCodeExporter commented 8 years ago 
Thanks very much for reporting back, and also for reporting the issue to the 
Cygwin mailing list (at http://cygwin.com/ml/cygwin/2013-06/msg00185.html).

I reproduced the issue, but found that xterm and rxvt are equally affected. 
Therefore this appears to be due to a longer-standing issue with Cygwin's pty 
layer.

Rejecting as not a mintty-specific issue.

Original comment by andy.koppe on 14 Jun 2013 at 11:50

GoogleCodeExporter commented 8 years ago 
ps: When normal 'kill' and 'kill -9' don't work, then '/bin/kill -f' will often 
still work. This terminates a process directly using the Windows API instead of 
going through Cygwin signals. (The full path with '/bin' is usually needed to 
avoid the shell's builtin 'kill' command, which doesn't have the -f option.)

Original comment by andy.koppe on 14 Jun 2013 at 12:07