Continuous Ctrl+C freezes Bash started via git-cmd #227

bviktor · 2015-06-29T14:49:59Z

Start a bash session with

c:\git\git-cmd.exe --command=usr\bin\bash.exe --login -i

Then keep pressing Ctrl+C. Within a minute (it's random, sometimes it's 2 seconds, sometimes it's 30) the shell will freeze and no longer respond to user input. Within another minute or so it'll return the prompt and display everything that's been typed in the meanwhile.

Always reproducible for me. Tested with 64 bit Git 2.4.5.1 on Windows 8.1 x64 and Windows 10 x64.

Related: #205

The text was updated successfully, but these errors were encountered:

dscho · 2015-08-17T13:48:58Z

I just tried it and can reproduce it. Unfortunately, I do not have enough time to look into it.

harriha · 2015-08-31T18:11:45Z

I'm seeing the same with latest 2.5.1. Seeing this occasionally, mostly when I have a file watcher such as chokidar-cli or nodemon running, exiting the process is painfully difficult.

Seen on Windows 10 and Windows 7 today.

ashelley · 2015-10-09T16:58:53Z

Hello,

I would like to confirm that I'm having this issue still on git 2.6.1 on windows 10.

Symptoms:

pressing ctrl+c when a program is running sporadically takes 10-60 seconds to return to the prompt. The process is killed instantly (but you can't really tell) and the time it takes for the $ prompt to show up is prolonged.

Here is how i can reproduce it albeit not a very minimal test case.

Step 1) make sure you have node installed (I don't think it matters what version since I believe this is a git-bash issue it seems)

Step 2) make sure you have node-dev installed (npm install -g node-dev), details below

Step 3) use this script app.js:

function run() {
   console.log('waiting 5 seconds');
   setTimeout(function() {
      run();
   }, 5000)
}
run();

Step 4) show that node works with ctrl+c (no delay issues)

$ node app.js
waiting 5 seconds
waiting 5 seconds
waiting 5 seconds
waiting 5 seconds
<ctrl+c>

Process exits normally here

Step 5) run with node-dev (sporadic delay issues). This might exit and return you to the command prompt right away but often it takes a long delay to get back to the command prompt

$ node-dev app.js
waiting 5 seconds
waiting 5 seconds
waiting 5 seconds
waiting 5 seconds
<ctrl+c>

If you hit ctrl+c right away it seems more likely it will exit fine. However after letting this loop a couple of times it seems to pretty consistently exhibit the "delay problem"

internally node-dev uses https://nodejs.org/docs/latest/api/fs.html#fs_fs_watchfile_filename_options_listener

which correlates to what @harriha has reported.

I know node has nothing to do with git but I just wanted to post my testcase so that it might help someone reproduce or confirm a fix.

-Adam

dscho · 2015-10-09T17:11:59Z

@ashelley thank you. This test case will indeed be incredibly valuable to verify a fix.

laggingreflex · 2015-10-20T06:00:44Z

Cygwin's bash.exe has the same issue. Does this (git-for-windows) use the same bash.exe as Cygwin's, or do they both have a same source? If so, the problem would be linked to it.

Similar issues for Cygwin's bash have been reported: http://google.com/search?q=cygwin+Ctrl-C

dscho · 2015-10-20T08:56:20Z

Does this (git-for-windows) uses the same bash.exe as Cygwin's

Yes. See https://github.com/git-for-windows/git/wiki#about for details.

clintwood · 2015-10-28T19:06:51Z

I'm having same issue with nodemon - using Sysinternals Process Explorer I notice that the process tree initially looks like this:

Then running nodemon it looks like this (notice that it has spawned sh.exe as a root process which is not in the original process tree below bash.exe):

Then after Ctrl-c it looks like this (notice that sh.exe is an orphaned process and not part of the original process tree):

Finally after about 60s the orphaned process (sh.exe) terminates and the prompt returns.

Prior to gfw 2.x sh.exe always existed in the process tree below bash.exe. Lastly I also noticed that uname.exe and a few other utility processes are all created as root processes which was not the case in pre 2.x gfw. Hope this helps!

clintwood · 2015-10-28T19:10:21Z

BTW this is not unique to git-bash.exe. I have the same issue using either bash.exe or sh.exe from via ConEmu. And it's really annoying... ;)

EDIT: @dscho any short term workarounds for this?

SystemDisc · 2015-10-30T09:14:58Z

In MinTTY, when using Ctrl+C to exit an HTTP server running in Node.JS, node.exe is always left open.
In ConEmu, when using Ctrl+C to exit an HTTP server running in Node.JS, node.exe occasionally hangs before closing, and an sh.exe sometimes hangs, too.

I'd like to also note that I've experienced all of the issues listed above, and that these issues have been happening for me since long before Git for Windows replaced MSYSGit

dscho · 2016-04-02T13:00:15Z

I believe that I fixed this with b7a95d0

bviktor · 2016-04-02T13:03:53Z

Actually, not quite. I can still reproduce it.

dscho · 2016-04-02T15:10:49Z

You're right, it freezes at random points.

Except that it does not really freeze. It does not react to input for an extended amount of time, but then comes back...

laggingreflex · 2016-04-02T20:21:22Z

As noted in my previous comment (and by other users as well), the issue is probably with Cygwin's bash itself. It must have been introduced somewhere between Cygwin bash v3 (works fine in Git 1.9) and v4

dscho · 2016-04-04T07:06:58Z

@laggingreflex thank you for weighing in.

The links in https://www.google.de/search?q=cygwin+Ctrl-C are unrelated for me, though: they show that Ctrl+C is not working at all for some people. Here, it is freezing after repeatedly hitting Ctrl+C.

Would you have a more concrete link that shows that this freezing behavior also occurs with Cygwin?

dscho · 2016-04-04T13:51:59Z

@laggingreflex hmpf. I went ahead and tried to freeze Cygwin's Bash in CMD in the same way as described in this ticket, and failed to reproduce it there. Could you try again and come back with your findings?

dscho · 2016-04-07T11:56:13Z

Further findings (these will be the last findings from my side at least for a while):

the freezes only happen if calling bin\bash, not usr\bin\bash, i.e. when running Bash through the Git wrapper.
very short before the freeze happens, the output of strace.exe shows that it is calling pinfo::maybe_set_exit_code_from_windows and that the windows exit value is 0xDEADBEEF, i.e. it is not available.
it seems that the ctrl_c_handler() function is entered at least twice when Ctrl+C is pressed, more times still when the freeze happens.
Most notably, when the freeze happens, the ctrl_c_handler() function is entered in two different processes. This is not the case when the freeze is not happening, then the function is entered in only one process (which is still not the main process, I think it is a separate process that is spawned for the sole purpose of sending the SIGINT signal, but it should not be spawned twice, which is what might be happening).

If anybody savvy enough could continue from here, that would be awesome!

dscho · 2017-05-15T21:45:53Z

So it looks as if nobody is really interested in fixing this. I wonder whether this bug is so critical after all.

SystemDisc · 2017-05-15T22:07:32Z

I'm definitely interested in getting this fixed but did not receive any notification from GitHub on this until your last comment (perhaps because you pre-emptively closed the issue? I have no idea). I'm also not sure how I can help.

dscho · 2017-05-15T22:24:08Z

@SystemDisc one way to help would be to start from my findings that I reported in this comment.

To continue, you need to build the MSYS2 runtime locally, and then patch in debug statements (e.g using small_printf() as described in https://github.com/git-for-windows/msys2-runtime/blob/7509443b9a90cffc4ed02ea456c1b4838e2a882b/winsup/cygwin/how-to-debug-cygwin.txt#L130-L134) in strategic places. The goal would be to find out which callers cause that dead-lock.

it is quite possible that the problem may lie with the kill_process_tree() function I introduced into the MSYS2 runtime: maybe it should not traverse children of MSYS2 processes, but I am not quite sure yet how MSYS2 can identify those. Maybe it has an internal enumeration of MSYS2 processes (if you launch ps without further arguments, you will see only MSYS2 processes, which makes me think that there should be an API, and I would try to find out about that by running strace -i log.txt ps and then scrolling backwards through that log.txt).

dscho · 2017-06-13T20:13:31Z

t is quite possible that the problem may lie with the kill_process_tree() function I introduced into the MSYS2 runtime

Alas, it is not. In v2.13.1, I changed the way Ctrl+C works and the problem described in this ticket still persists.

Any help would be very much appreciated.

SystemDisc · 2017-06-13T20:28:15Z

I have no idea how to debug this since I do not have enough experience debugging software written in C. For now, I've switched to using the Windows Subsystem for Linux (also referred to as Bash on Ubuntu on Windows) which comes with Windows 10.

kevison · 2017-12-08T16:10:34Z

Still a problem in 2.15....

This thing again... Background: when you hit Ctrl+C on Linux or macOS, a signal (SIGINT) is sent to the foreground process and its child processes. This signal can be intercepted by installing a signal handler for this specific signal. On Windows, there is no precise equivalent for this system. Instead, the Ctrl+C is translated by the current ConHost (i.e. the container running the Console processes) to a ConsoleCtrl event that is sent to all processes attached to that Console. If any of these processes installed a handler via SetConsoleCtrlHandler(), they can intercept that event (and avoid exiting or doing some cleanup work). On Linux and macOS (and every Unix flavor, really), processes can also be killed via the `kill` executable, which really just sends a signal to the process, typically SIGTERM. Processes can intercept that signal, too. To force processes to terminate, without giving them any chance to prevent that, SIGKILL can be sent. There is no equivalent for SIGTERM on Windows. To emulate SIGKILL on Windows, TerminateProcess() can be used, but it only kills one process (unlike SIGKILL, which is sent also to the child processes). In Git for Windows, we struggled with emulating SIGINT, SIGTERM and SIGKILL handling essentially since the beginning of the efforts to port Git to Windows. At least the SIGINT part of the problem becomes a lot worse when using a terminal window other than cmd.exe's: as long as using cmd.exe (AKA "ConHost"), Ctrl+C is handled entirely outside of our code. But with the big jump from v1.x to v2.x, Git for Windows not only switched from MSys to MSYS2, but also started using MinTTY as the default terminal window, which uses the MSYS2 runtime-provided pseudo terminals (inherited from Cygwin thanks to the MSYS2 runtime being a "friendly fork" of Cygwin). When Ctrl+C is pressed in MinTTY, all of the signaling has to be done by our code. The original code to handle Ctrl+C comes straight from Cygwin. It simply ignores the entire conundrum for non-Cygwin processes and simply calls TerminateProcess() on them, leaving spawned child processes running. The first attempt at fixing "the Ctrl+C problem" (with the symptom that interrupting `git clone ...` would not stop the actual download of the Git objects that was still running in a child process) was c4ba4e3357f. It simply enumerated all the processes' process IDs and parent process IDs and extracted the tree of (possibly transitive) child processes of the process to kill, then called TerminateProcess() on them. This solved the problem with interrupting `git clone`, but it did not address the problem that Git typically wants to "clean up" when being interrupted. In particular, Git installs atexit() and signal handlers to remove .lock files. The most common symptom was that a stale .git/index.lock file was still present after interrupting a Git process. Based on the idea presented in Dr Dobb's Journal in the article "A Safer Alternative to TerminateProcess()" by Andrew Tucker (July 1, 1999) http://www.drdobbs.com/a-safer-alternative-to-terminateprocess/184416547 we changed our handling to inject a remote thread calling ExitProcess() first, and fall back to TerminateProcess() the process tree instead: e9cb332976c This change was a little misguided in hindsight, as it only called TerminateProcess() on the process tree, but expected the atexit() handler of Git to take care of the child processes when killing the process via the remote ExitProcess() method. Therefore, we changed the strategy once again, to inject ExitProcess() threads into the child processes of the process to kill, too: 53e5c0313e1 (That commit also tries to handle Cygwin process among the child processes by sending Cygwin signals, but unfortunately that part of the commit was buggy.) This worked well for Git processes. However, Git Bash is used in all kinds of circumstances, including launching Maven, or node.js scripts that want to intercept SIGINT. Naturally, these callees have no idea that Git for Windows injects an ExitProcess() with exit code 130 (corresponding to 0x100 + SIGINT). Therefore, they never "got" the signal. So what is it that happens when ConHost generates a ConsoleCtrl event? This question was asked and answered in the excellent blog post at: http://stanislavs.org/stopping-command-line-applications-programatically-with-ctrl-c-events-from-net/#comment-2880 Essentially, the same happens as what we did with ExitProcess(): a remote thread gets injected, with the event type as parameter. Of course it is not ExitProcess() that is called, but CtrlRoutine(). This function lives in kernel32.dll, too, but it is not exported, i.e. GetProcAddress() won't find it. The trick proposed in the blog post (to send a test ConsoleCtrl event to the process itself, using a special handler that then inspects the stack trace to figure out the address of the caller) does not work for us, however: it would send a CTRL_BREAK_EVENT to *all* processes attached to the same Console, essentially killing MinTTY. But could we make this still work somehow? Yes, we could. We came up with yet another trick up our sleeves: instead of determining the address of kernel32!CtrlRoutine in our own process, we spawn a new one, with a new Console, to avoid killing MinTTY. To do that, we need a helper .exe, of course, which we put into /usr/libexec/. If this helper is not found, we fall back to the previous methods of injecting ExitProcess() or calling TerminateProcess(). This method (to spawn a helper .exe) has a further incidental benefit: by compiling 32-bit *and* 64-bit helpers and providing them as getprocaddr32.exe and getprocaddr64.exe, we can now also handle 32-bit processes in a 64-bit Git for Windows. Sadly not vice versa: calling CreateRemoteThread() on a 64-bit process from a 32-bit process seems to fail all the time (and require a lot of assembly hackery to fix that I am not really willing to include in Git for Windows' MSYS2 runtime). The current method was implemented in this commit: ca6188a7520 This is the hopeful final fix for git-for-windows/git#1491, git-for-windows/git#1470, git-for-windows/git#1248, git-for-windows/git#1239, git-for-windows/git#227, git-for-windows/git#1553, nodejs/node#16103, and plenty other tickets that petered out mostly due to a willingness of community members to leave all the hard work to a single, already overworked person. This fix also partially helps git-for-windows/git#1629 (only partially because the user wanted to quit the pager using Ctrl+C, which is not the intended consequence of a Ctrl+C: it should stop the Git process, but not the pager). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

This thing again... Background: when you hit Ctrl+C on Linux or macOS, a signal (SIGINT) is sent to the foreground process and its child processes. This signal can be intercepted by installing a signal handler for this specific signal. On Windows, there is no precise equivalent for this system. Instead, the Ctrl+C is translated by the current ConHost (i.e. the container running the Console processes) to a ConsoleCtrl event that is sent to all processes attached to that Console. If any of these processes installed a handler via SetConsoleCtrlHandler(), they can intercept that event (and avoid exiting or doing some cleanup work). On Linux and macOS (and every Unix flavor, really), processes can also be killed via the `kill` executable, which really just sends a signal to the process, typically SIGTERM. Processes can intercept that signal, too. To force processes to terminate, without giving them any chance to prevent that, SIGKILL can be sent. There is no equivalent for SIGTERM on Windows. To emulate SIGKILL on Windows, TerminateProcess() can be used, but it only kills one process (unlike SIGKILL, which is sent also to the child processes). In Git for Windows, we struggled with emulating SIGINT, SIGTERM and SIGKILL handling essentially since the beginning of the efforts to port Git to Windows. At least the SIGINT part of the problem becomes a lot worse when using a terminal window other than cmd.exe's: as long as using cmd.exe (AKA "ConHost"), Ctrl+C is handled entirely outside of our code. But with the big jump from v1.x to v2.x, Git for Windows not only switched from MSys to MSYS2, but also started using MinTTY as the default terminal window, which uses the MSYS2 runtime-provided pseudo terminals (inherited from Cygwin thanks to the MSYS2 runtime being a "friendly fork" of Cygwin). When Ctrl+C is pressed in MinTTY, all of the signaling has to be done by our code. The original code to handle Ctrl+C comes straight from Cygwin. It simply ignores the entire conundrum for non-Cygwin processes and simply calls TerminateProcess() on them, leaving spawned child processes running. The first attempt at fixing "the Ctrl+C problem" (with the symptom that interrupting `git clone ...` would not stop the actual download of the Git objects that was still running in a child process) was git-for-windows/msys2-runtime@c4ba4e3357f. It simply enumerated all the processes' process IDs and parent process IDs and extracted the tree of (possibly transitive) child processes of the process to kill, then called TerminateProcess() on them. This solved the problem with interrupting `git clone`, but it did not address the problem that Git typically wants to "clean up" when being interrupted. In particular, Git installs atexit() and signal handlers to remove .lock files. The most common symptom was that a stale .git/index.lock file was still present after interrupting a Git process. Based on the idea presented in Dr Dobb's Journal in the article "A Safer Alternative to TerminateProcess()" by Andrew Tucker (July 1, 1999) http://www.drdobbs.com/a-safer-alternative-to-terminateprocess/184416547 we changed our handling to inject a remote thread calling ExitProcess() first, and fall back to TerminateProcess() the process tree instead: git-for-windows/msys2-runtime@e9cb332976c This change was a little misguided in hindsight, as it only called TerminateProcess() on the process tree, but expected the atexit() handler of Git to take care of the child processes when killing the process via the remote ExitProcess() method. Therefore, we changed the strategy once again, to inject ExitProcess() threads into the child processes of the process to kill, too: git-for-windows/msys2-runtime@53e5c0313e1 (That commit also tries to handle Cygwin process among the child processes by sending Cygwin signals, but unfortunately that part of the commit was buggy.) This worked well for Git processes. However, Git Bash is used in all kinds of circumstances, including launching Maven, or node.js scripts that want to intercept SIGINT. Naturally, these callees have no idea that Git for Windows injects an ExitProcess() with exit code 130 (corresponding to 0x100 + SIGINT). Therefore, they never "got" the signal. So what is it that happens when ConHost generates a ConsoleCtrl event? This question was asked and answered in the excellent blog post at: http://stanislavs.org/stopping-command-line-applications-programatically-with-ctrl-c-events-from-net/#comment-2880 Essentially, the same happens as what we did with ExitProcess(): a remote thread gets injected, with the event type as parameter. Of course it is not ExitProcess() that is called, but CtrlRoutine(). This function lives in kernel32.dll, too, but it is not exported, i.e. GetProcAddress() won't find it. The trick proposed in the blog post (to send a test ConsoleCtrl event to the process itself, using a special handler that then inspects the stack trace to figure out the address of the caller) does not work for us, however: it would send a CTRL_BREAK_EVENT to *all* processes attached to the same Console, essentially killing MinTTY. But could we make this still work somehow? Yes, we could. We came up with yet another trick up our sleeves: instead of determining the address of kernel32!CtrlRoutine in our own process, we spawn a new one, with a new Console, to avoid killing MinTTY. To do that, we need a helper .exe, of course, which we put into /usr/libexec/. If this helper is not found, we fall back to the previous methods of injecting ExitProcess() or calling TerminateProcess(). This method (to spawn a helper .exe) has a further incidental benefit: by compiling 32-bit *and* 64-bit helpers and providing them as getprocaddr32.exe and getprocaddr64.exe, we can now also handle 32-bit processes in a 64-bit Git for Windows. Sadly not vice versa: calling CreateRemoteThread() on a 64-bit process from a 32-bit process seems to fail all the time (and require a lot of assembly hackery to fix that I am not really willing to include in Git for Windows' MSYS2 runtime). The current method was implemented in this commit: git-for-windows/msys2-runtime@ca6188a7520 This is the hopeful final fix for git-for-windows/git#1491, git-for-windows/git#1470, git-for-windows/git#1248, git-for-windows/git#1239, git-for-windows/git#227, git-for-windows/git#1553, nodejs/node#16103, and plenty other tickets that petered out mostly due to a willingness of community members to leave all the hard work to a single, already overworked person. This fix also partially helps git-for-windows/git#1629 (only partially because the user wanted to quit the pager using Ctrl+C, which is not the intended consequence of a Ctrl+C: it should stop the Git process, but not the pager). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

dscho · 2018-04-23T12:47:53Z

The newest snapshot at https://wingit.blob.core.windows.net/files/index.html should fix this. Please test.

avindra · 2018-04-23T14:37:10Z

@dscho Seems fixed for me! the only slowness now seems to be coming from the default PS1 which includes Git info. I'm using this:

PS1='\033[33m\]\w\[\033[36m\] \[\033[0m\] $ '

which renders a simplified PS1 without any Git branch:

dscho · 2018-04-25T08:49:19Z

Seems fixed for me!

Thanks for the feedback!

the only slowness now seems to be coming from the default PS1

That would be a different issue, though ;-)

This thing again... Background: when you hit Ctrl+C on Linux or macOS, a signal (SIGINT) is sent to the foreground process and its child processes. This signal can be intercepted by installing a signal handler for this specific signal. On Windows, there is no precise equivalent for this system. Instead, the Ctrl+C is translated by the current ConHost (i.e. the container running the Console processes) to a ConsoleCtrl event that is sent to all processes attached to that Console. If any of these processes installed a handler via SetConsoleCtrlHandler(), they can intercept that event (and avoid exiting or doing some cleanup work). On Linux and macOS (and every Unix flavor, really), processes can also be killed via the `kill` executable, which really just sends a signal to the process, typically SIGTERM. Processes can intercept that signal, too. To force processes to terminate, without giving them any chance to prevent that, SIGKILL can be sent. There is no equivalent for SIGTERM on Windows. To emulate SIGKILL on Windows, TerminateProcess() can be used, but it only kills one process (unlike SIGKILL, which is sent also to the child processes). In Git for Windows, we struggled with emulating SIGINT, SIGTERM and SIGKILL handling essentially since the beginning of the efforts to port Git to Windows. At least the SIGINT part of the problem becomes a lot worse when using a terminal window other than cmd.exe's: as long as using cmd.exe (AKA "ConHost"), Ctrl+C is handled entirely outside of our code. But with the big jump from v1.x to v2.x, Git for Windows not only switched from MSys to MSYS2, but also started using MinTTY as the default terminal window, which uses the MSYS2 runtime-provided pseudo terminals (inherited from Cygwin thanks to the MSYS2 runtime being a "friendly fork" of Cygwin). When Ctrl+C is pressed in MinTTY, all of the signaling has to be done by our code. The original code to handle Ctrl+C comes straight from Cygwin. It simply ignores the entire conundrum for non-Cygwin processes and simply calls TerminateProcess() on them, leaving spawned child processes running. The first attempt at fixing "the Ctrl+C problem" (with the symptom that interrupting `git clone ...` would not stop the actual download of the Git objects that was still running in a child process) was c4ba4e3357f. It simply enumerated all the processes' process IDs and parent process IDs and extracted the tree of (possibly transitive) child processes of the process to kill, then called TerminateProcess() on them. This solved the problem with interrupting `git clone`, but it did not address the problem that Git typically wants to "clean up" when being interrupted. In particular, Git installs atexit() and signal handlers to remove .lock files. The most common symptom was that a stale .git/index.lock file was still present after interrupting a Git process. Based on the idea presented in Dr Dobb's Journal in the article "A Safer Alternative to TerminateProcess()" by Andrew Tucker (July 1, 1999) http://www.drdobbs.com/a-safer-alternative-to-terminateprocess/184416547 we changed our handling to inject a remote thread calling ExitProcess() first, and fall back to TerminateProcess() the process tree instead: e9cb332976c This change was a little misguided in hindsight, as it only called TerminateProcess() on the process tree, but expected the atexit() handler of Git to take care of the child processes when killing the process via the remote ExitProcess() method. Therefore, we changed the strategy once again, to inject ExitProcess() threads into the child processes of the process to kill, too: 53e5c0313e1 (That commit also tries to handle Cygwin process among the child processes by sending Cygwin signals, but unfortunately that part of the commit was buggy.) This worked well for Git processes. However, Git Bash is used in all kinds of circumstances, including launching Maven, or node.js scripts that want to intercept SIGINT. Naturally, these callees have no idea that Git for Windows injects an ExitProcess() with exit code 130 (corresponding to 0x100 + SIGINT). Therefore, they never "got" the signal. So what is it that happens when ConHost generates a ConsoleCtrl event? This question was asked and answered in the excellent blog post at: http://stanislavs.org/stopping-command-line-applications-programatically-with-ctrl-c-events-from-net/#comment-2880 Essentially, the same happens as what we did with ExitProcess(): a remote thread gets injected, with the event type as parameter. Of course it is not ExitProcess() that is called, but CtrlRoutine(). This function lives in kernel32.dll, too, but it is not exported, i.e. GetProcAddress() won't find it. The trick proposed in the blog post (to send a test ConsoleCtrl event to the process itself, using a special handler that then inspects the stack trace to figure out the address of the caller) does not work for us, however: it would send a CTRL_BREAK_EVENT to *all* processes attached to the same Console, essentially killing MinTTY. But could we make this still work somehow? Yes, we could. We came up with yet another trick up our sleeves: instead of determining the address of kernel32!CtrlRoutine in our own process, we spawn a new one, with a new Console, to avoid killing MinTTY. To do that, we need a helper .exe, of course, which we put into /usr/libexec/. If this helper is not found, we fall back to the previous methods of injecting ExitProcess() or calling TerminateProcess(). This method (to spawn a helper .exe) has a further incidental benefit: by compiling 32-bit *and* 64-bit helpers and providing them as getprocaddr32.exe and getprocaddr64.exe, we can now also handle 32-bit processes in a 64-bit Git for Windows. Sadly not vice versa: calling CreateRemoteThread() on a 64-bit process from a 32-bit process seems to fail all the time (and require a lot of assembly hackery to fix that I am not really willing to include in Git for Windows' MSYS2 runtime). The current method was implemented in this commit: ca6188a7520 This is the hopeful final fix for git-for-windows/git#1491, git-for-windows/git#1470, git-for-windows/git#1248, git-for-windows/git#1239, git-for-windows/git#227, git-for-windows/git#1553, nodejs/node#16103, and plenty other tickets that petered out mostly due to a willingness of community members to leave all the hard work to a single, already overworked person. This fix also partially helps git-for-windows/git#1629 (only partially because the user wanted to quit the pager using Ctrl+C, which is not the intended consequence of a Ctrl+C: it should stop the Git process, but not the pager). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Koudy · 2018-12-21T21:32:27Z

Have this problem.
Git-2.20.1-64-bit on Windows 7 x64.

Upd. Work on Git-2.15.1.2-64-bit

This thing again... Background: when you hit Ctrl+C on Linux or macOS, a signal (SIGINT) is sent to the foreground process and its child processes. This signal can be intercepted by installing a signal handler for this specific signal. On Windows, there is no precise equivalent for this system. Instead, the Ctrl+C is translated by the current ConHost (i.e. the container running the Console processes) to a ConsoleCtrl event that is sent to all processes attached to that Console. If any of these processes installed a handler via SetConsoleCtrlHandler(), they can intercept that event (and avoid exiting or doing some cleanup work). On Linux and macOS (and every Unix flavor, really), processes can also be killed via the `kill` executable, which really just sends a signal to the process, typically SIGTERM. Processes can intercept that signal, too. To force processes to terminate, without giving them any chance to prevent that, SIGKILL can be sent. There is no equivalent for SIGTERM on Windows. To emulate SIGKILL on Windows, TerminateProcess() can be used, but it only kills one process (unlike SIGKILL, which is sent also to the child processes). In Git for Windows, we struggled with emulating SIGINT, SIGTERM and SIGKILL handling essentially since the beginning of the efforts to port Git to Windows. At least the SIGINT part of the problem becomes a lot worse when using a terminal window other than cmd.exe's: as long as using cmd.exe (AKA "ConHost"), Ctrl+C is handled entirely outside of our code. But with the big jump from v1.x to v2.x, Git for Windows not only switched from MSys to MSYS2, but also started using MinTTY as the default terminal window, which uses the MSYS2 runtime-provided pseudo terminals (inherited from Cygwin thanks to the MSYS2 runtime being a "friendly fork" of Cygwin). When Ctrl+C is pressed in MinTTY, all of the signaling has to be done by our code. The original code to handle Ctrl+C comes straight from Cygwin. It simply ignores the entire conundrum for non-Cygwin processes and simply calls TerminateProcess() on them, leaving spawned child processes running. The first attempt at fixing "the Ctrl+C problem" (with the symptom that interrupting `git clone ...` would not stop the actual download of the Git objects that was still running in a child process) was c4ba4e3357f. It simply enumerated all the processes' process IDs and parent process IDs and extracted the tree of (possibly transitive) child processes of the process to kill, then called TerminateProcess() on them. This solved the problem with interrupting `git clone`, but it did not address the problem that Git typically wants to "clean up" when being interrupted. In particular, Git installs atexit() and signal handlers to remove .lock files. The most common symptom was that a stale .git/index.lock file was still present after interrupting a Git process. Based on the idea presented in Dr Dobb's Journal in the article "A Safer Alternative to TerminateProcess()" by Andrew Tucker (July 1, 1999) http://www.drdobbs.com/a-safer-alternative-to-terminateprocess/184416547 we changed our handling to inject a remote thread calling ExitProcess() first, and fall back to TerminateProcess() the process tree instead: e9cb332976c This change was a little misguided in hindsight, as it only called TerminateProcess() on the process tree, but expected the atexit() handler of Git to take care of the child processes when killing the process via the remote ExitProcess() method. Therefore, we changed the strategy once again, to inject ExitProcess() threads into the child processes of the process to kill, too: 53e5c0313e1 (That commit also tries to handle Cygwin process among the child processes by sending Cygwin signals, but unfortunately that part of the commit was buggy.) This worked well for Git processes. However, Git Bash is used in all kinds of circumstances, including launching Maven, or node.js scripts that want to intercept SIGINT. Naturally, these callees have no idea that Git for Windows injects an ExitProcess() with exit code 130 (corresponding to 0x100 + SIGINT). Therefore, they never "got" the signal. So what is it that happens when ConHost generates a ConsoleCtrl event? This question was asked and answered in the excellent blog post at: http://stanislavs.org/stopping-command-line-applications-programatically-with-ctrl-c-events-from-net/#comment-2880 Essentially, the same happens as what we did with ExitProcess(): a remote thread gets injected, with the event type as parameter. Of course it is not ExitProcess() that is called, but CtrlRoutine(). This function lives in kernel32.dll, too, but it is not exported, i.e. GetProcAddress() won't find it. The trick proposed in the blog post (to send a test ConsoleCtrl event to the process itself, using a special handler that then inspects the stack trace to figure out the address of the caller) does not work for us, however: it would send a CTRL_BREAK_EVENT to *all* processes attached to the same Console, essentially killing MinTTY. But could we make this still work somehow? Yes, we could. We came up with yet another trick up our sleeves: instead of determining the address of kernel32!CtrlRoutine in our own process, we spawn a new one, with a new Console, to avoid killing MinTTY. To do that, we need a helper .exe, of course, which we put into /usr/libexec/. If this helper is not found, we fall back to the previous methods of injecting ExitProcess() or calling TerminateProcess(). This method (to spawn a helper .exe) has a further incidental benefit: by compiling 32-bit *and* 64-bit helpers and providing them as getprocaddr32.exe and getprocaddr64.exe, we can now also handle 32-bit processes in a 64-bit Git for Windows. Sadly not vice versa: calling CreateRemoteThread() on a 64-bit process from a 32-bit process seems to fail all the time (and require a lot of assembly hackery to fix that I am not really willing to include in Git for Windows' MSYS2 runtime). The current method was implemented in this commit: ca6188a7520 This is the hopeful final fix for git-for-windows/git#1491, git-for-windows/git#1470, git-for-windows/git#1248, git-for-windows/git#1239, git-for-windows/git#227, git-for-windows/git#1553, nodejs/node#16103, and plenty other tickets that petered out mostly due to a willingness of community members to leave all the hard work to a single, already overworked person. This fix also partially helps git-for-windows/git#1629 (only partially because the user wanted to quit the pager using Ctrl+C, which is not the intended consequence of a Ctrl+C: it should stop the Git process, but not the pager). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

This replaces git-for-windows#223. There was a strangely-subtle issue about reading the trailing hash from the downloaded packs that caused issues when reading from the origin remote. Add `gvfs-helper prefetch` command line option and `objects.prefetch` mode in `gvfs-helper server`. Sorry, but this contains a major refactor of the packfile and loose file handling to let me share it with the prefetch code. As a side benefit, I collapsed the tempfile creation before the request goes out and merged the install_ code after the result is returned. I also changed packfile code to use the packfile-checksum rather than a timestamp so that we look more like normal Git. More details are in the commit message.

… "git fetch" This is a follow-up to git-for-windows#227. 1. When a new flag is added to our Git config, we can run `gvfs-helper prefetch` inside of our `git fetch` calls. This will help ensure we have updated commits and trees even if the background prefetches have fallen behind (or are not running). 2. With a new `--no-update-remote-refs` we can avoid updating the `refs/remotes` namespace. This will allow us to run `git fetch --all --no-update-remote-refs +refs/heads/*:refs/hidden/*` and we will get the new refs into a local folder (that doesn't appear anywhere). The most important thing is that users will still see when their remote refs update.

This replaces git-for-windows#223. There was a strangely-subtle issue about reading the trailing hash from the downloaded packs that caused issues when reading from the origin remote. Add `gvfs-helper prefetch` command line option and `objects.prefetch` mode in `gvfs-helper server`. Sorry, but this contains a major refactor of the packfile and loose file handling to let me share it with the prefetch code. As a side benefit, I collapsed the tempfile creation before the request goes out and merged the install_ code after the result is returned. I also changed packfile code to use the packfile-checksum rather than a timestamp so that we look more like normal Git. More details are in the commit message.

… "git fetch" This is a follow-up to git-for-windows#227. 1. When a new flag is added to our Git config, we can run `gvfs-helper prefetch` inside of our `git fetch` calls. This will help ensure we have updated commits and trees even if the background prefetches have fallen behind (or are not running). 2. With a new `--no-update-remote-refs` we can avoid updating the `refs/remotes` namespace. This will allow us to run `git fetch --all --no-update-remote-refs +refs/heads/*:refs/hidden/*` and we will get the new refs into a local folder (that doesn't appear anywhere). The most important thing is that users will still see when their remote refs update.

This replaces git-for-windows#223. There was a strangely-subtle issue about reading the trailing hash from the downloaded packs that caused issues when reading from the origin remote. Add `gvfs-helper prefetch` command line option and `objects.prefetch` mode in `gvfs-helper server`. Sorry, but this contains a major refactor of the packfile and loose file handling to let me share it with the prefetch code. As a side benefit, I collapsed the tempfile creation before the request goes out and merged the install_ code after the result is returned. I also changed packfile code to use the packfile-checksum rather than a timestamp so that we look more like normal Git. More details are in the commit message.

… "git fetch" This is a follow-up to git-for-windows#227. 1. When a new flag is added to our Git config, we can run `gvfs-helper prefetch` inside of our `git fetch` calls. This will help ensure we have updated commits and trees even if the background prefetches have fallen behind (or are not running). 2. With a new `--no-update-remote-refs` we can avoid updating the `refs/remotes` namespace. This will allow us to run `git fetch --all --no-update-remote-refs +refs/heads/*:refs/hidden/*` and we will get the new refs into a local folder (that doesn't appear anywhere). The most important thing is that users will still see when their remote refs update.

Includes these pull requests: git-for-windows#227 git-for-windows#228 git-for-windows#229 git-for-windows#231 git-for-windows#240 Signed-off-by: Derrick Stolee <dstolee@microsoft.com>

This thing again... Background: when you hit Ctrl+C on Linux or macOS, a signal (SIGINT) is sent to the foreground process and its child processes. This signal can be intercepted by installing a signal handler for this specific signal. On Windows, there is no precise equivalent for this system. Instead, the Ctrl+C is translated by the current ConHost (i.e. the container running the Console processes) to a ConsoleCtrl event that is sent to all processes attached to that Console. If any of these processes installed a handler via SetConsoleCtrlHandler(), they can intercept that event (and avoid exiting or doing some cleanup work). On Linux and macOS (and every Unix flavor, really), processes can also be killed via the `kill` executable, which really just sends a signal to the process, typically SIGTERM. Processes can intercept that signal, too. To force processes to terminate, without giving them any chance to prevent that, SIGKILL can be sent. There is no equivalent for SIGTERM on Windows. To emulate SIGKILL on Windows, TerminateProcess() can be used, but it only kills one process (unlike SIGKILL, which is sent also to the child processes). In Git for Windows, we struggled with emulating SIGINT, SIGTERM and SIGKILL handling essentially since the beginning of the efforts to port Git to Windows. At least the SIGINT part of the problem becomes a lot worse when using a terminal window other than cmd.exe's: as long as using cmd.exe (AKA "ConHost"), Ctrl+C is handled entirely outside of our code. But with the big jump from v1.x to v2.x, Git for Windows not only switched from MSys to MSYS2, but also started using MinTTY as the default terminal window, which uses the MSYS2 runtime-provided pseudo terminals (inherited from Cygwin thanks to the MSYS2 runtime being a "friendly fork" of Cygwin). When Ctrl+C is pressed in MinTTY, all of the signaling has to be done by our code. The original code to handle Ctrl+C comes straight from Cygwin. It simply ignores the entire conundrum for non-Cygwin processes and simply calls TerminateProcess() on them, leaving spawned child processes running. The first attempt at fixing "the Ctrl+C problem" (with the symptom that interrupting `git clone ...` would not stop the actual download of the Git objects that was still running in a child process) was git-for-windows/msys2-runtime@c4ba4e3357f. It simply enumerated all the processes' process IDs and parent process IDs and extracted the tree of (possibly transitive) child processes of the process to kill, then called TerminateProcess() on them. This solved the problem with interrupting `git clone`, but it did not address the problem that Git typically wants to "clean up" when being interrupted. In particular, Git installs atexit() and signal handlers to remove .lock files. The most common symptom was that a stale .git/index.lock file was still present after interrupting a Git process. Based on the idea presented in Dr Dobb's Journal in the article "A Safer Alternative to TerminateProcess()" by Andrew Tucker (July 1, 1999) http://www.drdobbs.com/a-safer-alternative-to-terminateprocess/184416547 we changed our handling to inject a remote thread calling ExitProcess() first, and fall back to TerminateProcess() the process tree instead: git-for-windows/msys2-runtime@e9cb332976c This change was a little misguided in hindsight, as it only called TerminateProcess() on the process tree, but expected the atexit() handler of Git to take care of the child processes when killing the process via the remote ExitProcess() method. Therefore, we changed the strategy once again, to inject ExitProcess() threads into the child processes of the process to kill, too: git-for-windows/msys2-runtime@53e5c0313e1 (That commit also tries to handle Cygwin process among the child processes by sending Cygwin signals, but unfortunately that part of the commit was buggy.) This worked well for Git processes. However, Git Bash is used in all kinds of circumstances, including launching Maven, or node.js scripts that want to intercept SIGINT. Naturally, these callees have no idea that Git for Windows injects an ExitProcess() with exit code 130 (corresponding to 0x100 + SIGINT). Therefore, they never "got" the signal. So what is it that happens when ConHost generates a ConsoleCtrl event? This question was asked and answered in the excellent blog post at: http://stanislavs.org/stopping-command-line-applications-programatically-with-ctrl-c-events-from-net/#comment-2880 Essentially, the same happens as what we did with ExitProcess(): a remote thread gets injected, with the event type as parameter. Of course it is not ExitProcess() that is called, but CtrlRoutine(). This function lives in kernel32.dll, too, but it is not exported, i.e. GetProcAddress() won't find it. The trick proposed in the blog post (to send a test ConsoleCtrl event to the process itself, using a special handler that then inspects the stack trace to figure out the address of the caller) does not work for us, however: it would send a CTRL_BREAK_EVENT to *all* processes attached to the same Console, essentially killing MinTTY. But could we make this still work somehow? Yes, we could. We came up with yet another trick up our sleeves: instead of determining the address of kernel32!CtrlRoutine in our own process, we spawn a new one, with a new Console, to avoid killing MinTTY. To do that, we need a helper .exe, of course, which we put into /usr/libexec/. If this helper is not found, we fall back to the previous methods of injecting ExitProcess() or calling TerminateProcess(). This method (to spawn a helper .exe) has a further incidental benefit: by compiling 32-bit *and* 64-bit helpers and providing them as getprocaddr32.exe and getprocaddr64.exe, we can now also handle 32-bit processes in a 64-bit Git for Windows. Sadly not vice versa: calling CreateRemoteThread() on a 64-bit process from a 32-bit process seems to fail all the time (and require a lot of assembly hackery to fix that I am not really willing to include in Git for Windows' MSYS2 runtime). The current method was implemented in this commit: git-for-windows/msys2-runtime@ca6188a7520 This is the hopeful final fix for git-for-windows/git#1491, git-for-windows/git#1470, git-for-windows/git#1248, git-for-windows/git#1239, git-for-windows/git#227, git-for-windows/git#1553, nodejs/node#16103, and plenty other tickets that petered out mostly due to a willingness of community members to leave all the hard work to a single, already overworked person. This fix also partially helps git-for-windows/git#1629 (only partially because the user wanted to quit the pager using Ctrl+C, which is not the intended consequence of a Ctrl+C: it should stop the Git process, but not the pager). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Includes these pull requests: git-for-windows#227 git-for-windows#228 git-for-windows#229 git-for-windows#231 git-for-windows#240 Signed-off-by: Derrick Stolee <dstolee@microsoft.com>

dscho added the up for grabs label Jul 16, 2015

dscho mentioned this issue Aug 17, 2015

CTRL-C event kills the application #205

Closed

Stanzilla mentioned this issue Sep 12, 2015

Extremely unresponsive behavior using Git for windows 2.5.x cmderdev/cmder#635

Closed

raulmatei mentioned this issue Mar 8, 2016

ConEmu long delay on Ctrl+C with GitBash Maximus5/ConEmu#402

Closed

dscho closed this as completed Apr 2, 2016

dscho reopened this Apr 2, 2016

ztou mentioned this issue Feb 11, 2017

bash hangs up after run "git log" and "CTRL+C" #1058

Closed

CherryDT mentioned this issue Apr 21, 2017

Ctrl-C doesn't terminate process or clear the line microsoft/node-pty#7

Closed

dscho closed this as completed Apr 25, 2018

dscho added this to the v2.17.0(2) milestone Apr 25, 2018

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Continuous Ctrl+C freezes Bash started via git-cmd #227

Continuous Ctrl+C freezes Bash started via git-cmd #227

bviktor commented Jun 29, 2015

dscho commented Aug 17, 2015

harriha commented Aug 31, 2015

ashelley commented Oct 9, 2015

dscho commented Oct 9, 2015

laggingreflex commented Oct 20, 2015

dscho commented Oct 20, 2015

clintwood commented Oct 28, 2015

clintwood commented Oct 28, 2015

SystemDisc commented Oct 30, 2015

dscho commented Apr 2, 2016

bviktor commented Apr 2, 2016

dscho commented Apr 2, 2016

laggingreflex commented Apr 2, 2016

dscho commented Apr 4, 2016

dscho commented Apr 4, 2016

dscho commented Apr 7, 2016

dscho commented May 15, 2017

SystemDisc commented May 15, 2017 •

edited

Loading

dscho commented May 15, 2017

dscho commented Jun 13, 2017

SystemDisc commented Jun 13, 2017 via email •

edited

Loading

kevison commented Dec 8, 2017

dscho commented Apr 23, 2018

avindra commented Apr 23, 2018

dscho commented Apr 25, 2018

Koudy commented Dec 21, 2018 •

edited

Loading

Continuous Ctrl+C freezes Bash started via git-cmd #227

Continuous Ctrl+C freezes Bash started via git-cmd #227

Comments

bviktor commented Jun 29, 2015

dscho commented Aug 17, 2015

harriha commented Aug 31, 2015

ashelley commented Oct 9, 2015

dscho commented Oct 9, 2015

laggingreflex commented Oct 20, 2015

dscho commented Oct 20, 2015

clintwood commented Oct 28, 2015

clintwood commented Oct 28, 2015

SystemDisc commented Oct 30, 2015

dscho commented Apr 2, 2016

bviktor commented Apr 2, 2016

dscho commented Apr 2, 2016

laggingreflex commented Apr 2, 2016

dscho commented Apr 4, 2016

dscho commented Apr 4, 2016

dscho commented Apr 7, 2016

dscho commented May 15, 2017

SystemDisc commented May 15, 2017 • edited Loading

dscho commented May 15, 2017

dscho commented Jun 13, 2017

SystemDisc commented Jun 13, 2017 via email • edited Loading

kevison commented Dec 8, 2017

dscho commented Apr 23, 2018

avindra commented Apr 23, 2018

dscho commented Apr 25, 2018

Koudy commented Dec 21, 2018 • edited Loading

SystemDisc commented May 15, 2017 •

edited

Loading

SystemDisc commented Jun 13, 2017 via email •

edited

Loading

Koudy commented Dec 21, 2018 •

edited

Loading