Git: Continuous Ctrl+C freezes Bash started via git-cmd

[bviktor]

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

[dscho]

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

[harriha]

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]

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]

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

[laggingreflex]

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]

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]

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]

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]

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]

I believe that I fixed this with https://github.com/git-for-windows/git/commit/b7a95d0be09864f073e6f75b4e0680b9955055a2

[bviktor]

Actually, not quite. I can still reproduce it.

[dscho]

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]

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]

@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]

@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]

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]

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

[SystemDisc]

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]

@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]

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]

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]

Still a problem in 2.15....

[dscho]

After testing this with my fix for https://github.com/git-for-windows/git/issues/1491 (which will hit https://wingit.blob.core.windows.net/files/index.html soon, so you can verify my claim, and you should, if you are interested in this issue) it would appear that there is no longer a freeze (although quite a bit of delay if you hit Ctrl+C tons of times).

[dscho]

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

[avindra]

@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]

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 ;-)

[Koudy]

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

Upd. Work on Git-2.15.1.2-64-bit