bug#70544: 30.0.50; The primitive-function "call-process-region" returns "internal error" and causes high cpu usage on win10

[Eli Zaretskii <eliz@gnu.org>]

> From: leuven65 <leuven65@gmail.com>
> Date: Wed, 24 Apr 2024 10:12:10 +0200
> Cc: 70544@debbugs.gnu.org
> 
> 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.

Maybe this gitk was supposed to be invoked only from the MSYS Bash?
If so, this is not really a problem with Emacs.

> 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.

I guess these all are related to the fact that gitk is not a console
problem, but a GUI problem, and therefore should not be invoked from
shell-command, at least not safely.  It was probably meant to be
invoked from a shell directly, and perhaps specifically from the MSYS
Bash which comes with Git for Windows.

Bottom line: I'm not convinced this is an Emacs problem, and I still
don't understand why you gitk from Emacs in this manner.

In any case, to do anything with this problem, we need either a way to
reproduce it on the system of one of our developers, or a detailed
information regarding the reasons why Emacs is spinning calling
MsgWaitForMultipleObjects.