I use the latest version "[[
https://github.com/git-for-windows/git/releases/tag/v2.44.0.windows.1]]", in which "a couple of
bugs that could cause Git Bash to hang in certain scenarios were fixed", it might cause the exit behavior of "gitk.exe"
changed.
The program gitk is "${git-installation-folder}/cmd/gitk.exe".
The issue only pops up when I set "(setq-default shell-file-name "cmdproxy.exe")", if set to "bash.exe", no such
problem.
When the issue happens, emacs is not blocked, I can smoothly input in emacs, but the cpu usage of emacs is very high
forever. As I built emacs without debug information, what I can see so far is that most of time seems to be spent on
"MsgWaitForMultipleObjects".
I use "shell-command" (M-!) to run "gitk.exe", the correct behavior is to run "gitk" and block emacs, or exit with
error, in my case, it prints out error "(Shell command killed by signal internal error)" and cpu usage goes up.
From the call stack, "shell-command" calls "call-process-region":
#+begin_quote
Debugger entered--entering a function:
,* call-process-region(324 324 "cmdproxy.exe" nil #<buffer *Shell Command Output*> nil "-c" "gitk.exe")
apply(call-process-region 324 324 "cmdproxy.exe" (nil #<buffer *Shell Command Output*> nil "-c" "gitk.exe"))
call-shell-region(324 324 "gitk.exe" nil #<buffer *Shell Command Output*>)
shell-command-on-region(324 324 "gitk.exe" nil nil nil)
shell-command("gitk.exe" nil nil)
funcall-interactively(shell-command "gitk.exe" nil nil)
command-execute(shell-command)
#+end_quote