search

suzdraws / mintty

Automatically exported from code.google.com/p/mintty
0 stars 0 forks source link

MinTTY hangs the console/shell it launched from on Win7-64 #83

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. Start bash shell in cmd.exe
2. Start mintty and then quit it, or just start mintty&

What is the expected output? What do you see instead?
Expect that the cmd->bash should go back to normal.  Instead, the cmd
becomes completely unresponsive.  Occasionally I also get a "Console Window
Host has stopped working" after I close the cmd.

What version of the product are you using? On what operating system?
MinTTY svn-r234; cygwin 1.7.0-45; Windows 7 x64 build 7000

Please provide any additional information below.

I thought this might be related to the fix for issue 39, but r229 also
shows this behavior.

Things that DO work:
Starting MinTTY from the shortcut
Running cmd.exe -> mintty directly
Running cmd.exe -> bash -c mintty

Original issue reported on code.google.com by cuviper on 4 Apr 2009 at 7:26

GoogleCodeExporter commented 9 years ago 
Can't reproduce on 32-bit Win7. :(

This doesn't seem likely to be mintty's fault though. Bash shouldn't hang no 
matter
what the child process does. How do rxvt and xterm fare?

Original comment by andy.koppe on 4 Apr 2009 at 8:27

GoogleCodeExporter commented 9 years ago 
xterm is fine, and so is the native-gui rxvt.  (The X rxvt crashes with DLL 
remapping
errors.)  I must have messed up my revision testing though, because I tried r229
again and it was fine.  It's definitely broken in r230 though, so it probably 
is the
console-hiding stuff to blame after all...

Anyway, it's not just bash hanging -- the entire console is hosed.  Selection 
doesn't
do anything.  I can bring up the system menu, but the cmd-specific actions (edit
submenu, defaults, properties) don't do anything.  Resizing the window causes 
it to
go blank, probably waiting to repaint.

Original comment by cuviper on 4 Apr 2009 at 9:23

GoogleCodeExporter commented 9 years ago 
Thanks Josh.

As you've probably already seen in the source, MinTTY calls AttachConsole(-1) 
in the
main process, and then again in the child process, in order to pass any existing
console down to the command executed in the child process. If none exists, it 
creates
one using AllocConsole() and hides its window with ShowWindowAsync().

Unfortunately I've got no idea why that should mess up the parent console or 
why it
should show on 64-bit but not 32-bit. Perhaps I should try again to get the rxvt
approach for hiding the console working.

Original comment by andy.koppe on 5 Apr 2009 at 10:39

GoogleCodeExporter commented 9 years ago

Original comment by andy.koppe on 5 Apr 2009 at 10:40

GoogleCodeExporter commented 9 years ago 
I tried running from the 32-bit %WINDIR%\SysWOW64\cmd.exe, but that didn't 
help.  I
did notice though that conhost.exe is still native 64-bit even for a 32-bit 
cmd.exe
process.  Who knows though -- all this win7 console behavior is acting 
bizarrely...

Another interesting point is that even with launching mintty directly from cmd, 
which
doesn't crash, I still get the new console flicker.  So it doesn't seem to be
correctly attaching the console anyway.

If I take out the AttachConsole call from just the child, it works just fine.  
Of
course, that then prevents console reuse, so every new mintty then gets the 
console
flicker.  That's better than a hang though, so I would suggest just removing 
all of
the AttachConsole code.

Original comment by cuviper on 6 Apr 2009 at 4:21

GoogleCodeExporter commented 9 years ago 
Removed the AttachConsole code as suggested, in r239 on trunk. As mentioned on 
issue
39 though, the window station trick doesn't seem to work on Windows 7, so sadly 
the
console flicker is here to stay (for the moment anyway).

Original comment by andy.koppe on 15 Apr 2009 at 5:39

GoogleCodeExporter commented 9 years ago 
Took fix to 0.3 branch in r248.

Original comment by andy.koppe on 24 Apr 2009 at 8:47

GoogleCodeExporter commented 9 years ago

Original comment by andy.koppe on 25 Apr 2009 at 12:03