mintty doesn't close/exit

[sledgehammer999]

I am using 2.6.3 64bits on Windows 7. I updated yesterday from 2.4.something. (I can't remember if it was 64bits too).

Here's my problem. Sometimes, but often enought to become an annoyance, the mintty window refuses to close no matter how many times I click on the "X" button. Even issuing exit in the terminal doesn't do something.
My only option is to kill the bash.exe from Task Manager.

How can I help you debug this?

[dscho]

Is bash.exe still running some command inside the MinTTY?

[sledgehammer999]

Not that I know of. I mean, that I hadn't issued any command. If there is some background task then I don't know.

[dscho]

@sledgehammer999 please try to list every detail you can think of (waiting for me to ask all of the things I can think of is just a bit tedious for both of us). So for example, you should consider trying to run things after clicking the X. And maybe test more systematically in order to get a reliable way to trigger the problem. You may also want to mention whether the cursor is still blinking, whether the letters you type still show up, etc, etc.

[sledgehammer999]

OK, I figured out how I can reproduce it. If I just open the terminal window and then close it, it doesn't have any problem. If I run any command either git command(eg git status) or regular (ls) AND then try to close it, it doesn't close. Furthermore, after it doesn't close no matter which command I issue it gets stuck there after the "enter". The cursor blinks at all times but the command doesn't finish. It doesn't even respond to "control-c". While stuck, if I write letters or hit enter they show up in the terminal.
However, if I don't try to close it, it executes every command.

Also another reliable way to make it exit is to issue exit in the terminal. exit gets stuck if I first try to close via "X".

I don't know how this works but I suppose mintty forwards things to bash, right? So maybe mintty does something weird (deadlock?) when clicking on "X".

I don't see any CPU activity on bash.exe or mintty.exe when they're stuck. Nor disk activity.

[dscho]

Hrm. I still cannot reproduce. If I open a Git Bash, run ls and click the X as quickly as possible (the ls command has finished by that time, of course), it closes Just Fine.

So I still think that there must be something odd in your setup that you did not think to mention yet.

[sledgehammer999]

I also checked with 2.6.2, 2.6.1, 2.6.0 and 2.5.3 64bits same problem.
Then I randomly installed 2.6.3 32bits and I no longer encounter the problem.

[dscho]

That is even stranger now!

The last idea I have about this is: is there an aggressive anti virus or other monitoring process running?

[sledgehammer999]

I tested in a VM with clean install of Win 7 sp2 and 64bit git. It works. So it surely is something wrong in my current setup.
I disabled my antivirus and firewall but it didn't fix it. I don't have any other monitoring app.
Hmm, I know this is hard for you to guess now.
Could you tell me how the interaction between mintty and bash works? Or at least how the "click on X" is handled by mintty and forwarded to the bash process? Or point me to the relevant code in the repo?
I might get an idea on what to look for in my machine...

[dscho]

how the "click on X" is handled by mintty

That code is in the mintty project. I guess the X is handled here: https://github.com/mintty/mintty/blob/1477cbd67e31882a2c812ae1307e1cd2de389c79/src/winmain.c#L962-L965

As you can see, there is a slightly different behavior if the Shift key is pressed (or if mintty thinks that it is pressed).

If I were in your shoes, I would install the Git for Windows SDK, then build the MSys2 package mintty as described here, then instrument the code in a way similar to this patch:

diff --git a/src/winmain.c b/src/winmain.c
index 1a9c5ab..ad43985 100644
--- a/src/winmain.c
+++ b/src/winmain.c
@@ -688,7 +688,9 @@ win_proc(HWND wnd, UINT message, WPARAM wp, LPARAM lp)
     }
     when WM_CLOSE:
       if (!cfg.confirm_exit || confirm_exit())
+{ FILE *f = fopen("C:\\git-sdk-64\\mintty.log", "a"); fprintf(f, "WM_CLOSE received (shift: %x)\n", GetKeyState(VK_SHIFT) & 0x80); fclose(f);
         child_kill((GetKeyState(VK_SHIFT) & 0x80) != 0);
+}
       return 0;
     when WM_COMMAND or WM_SYSCOMMAND:
       switch (wp & ~0xF) {  /* low 4 bits reserved to Windows */

then run make in /usr/src/MSYS2-packages/mintty/src/mintty-2.1.5, and then copy the src/mintty.exe file into a fresh PortableGit for further testing.

[sledgehammer999]

I have more info.
Last known working 64bit release from you guys, was 2.5.1.
I copied bash.exe, git-bash.exe and mintty.exe from 2.5.1 to 2.6.3 but the problem persists. Does that mean that mintty isn't at fault here?

[dscho]

It may be an issue with msys-2.0.dll, too.

Please note that 2.5.1 -> 2.6.3 is a pretty large jump, and much larger still when you realize that the individual packages we packaged went through their own sets of releases (check /etc/package-versions.txt for details).

[sledgehammer999]

The problem is between 2.5.1 and 2.5.2 and I imagine the jump isn't great there. I'll try the msys-2.0.dll from 2.5.1 into the 2.5.2 installation and report back.