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

From: [email-masked] (GNU bug Tracking System)
Date: Sat, 25 May 2024 07:42:03 +0000

Your bug report

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

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
70544: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=70544
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#70544: 30.0.50; The primitive-function "call-process-region" returns "internal error" and causes high cpu usage on win10
From: Eli Zaretskii <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Sat, 25 May 2024 10:40:48 +0300
List-Id: <debbugs-submit.debbugs.gnu.org>

> Cc: [email-masked]
> Date: Thu, 09 May 2024 10:16:12 +0300
> From: Eli Zaretskii <[email-masked]>
> 
> tags 70544 moreinfo
> thanks
> 
> Ping!  Can anyone reproduce this and/or tell more about what gitk.exe
> wants and why it fails?
> 
> If no additional information emerges in a two-weeks time, I will close
> this bug due to lack of sufficient information.

No further comments, so I'm closing this bug.  If new information
emerges, please reopen and continue the discussion of possible fixes.

> 
> > Cc: [email-masked]
> > Date: Wed, 24 Apr 2024 11:25:15 +0300
> > From: Eli Zaretskii <[email-masked]>
> > 
> > > From: leuven65 <[email-masked]>
> > > Date: Wed, 24 Apr 2024 10:12:10 +0200
> > > Cc: [email-masked]
> > > 
> > > 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.
> > 
> > 
> > 
> > 
> 
> 
> 
> 

Subject: 30.0.50; The primitive-function "call-process-region" returns "internal error" and causes high cpu usage on win10
From: leuven65 <[email-masked]>
To: [email-masked]
Date: Tue, 23 Apr 2024 20:02:39 +0200
List-Id: <debbugs-submit.debbugs.gnu.org>

On windows10, I uses git for windows, but when I execute "gitk" by
"shell-command"
in emacs, it returns an error "internal error",
and emacs's cpu usage becomes full forever, except for restarting emacs,
It seems emacs might process something wrong in this case.

The issue can be easily reproduced by directly eval following sexp:

(call-process-region (point-min) (point-max)
                     "cmdproxy.exe"
                     t
                     t
                     nil
                     "-c"
                     "gitk")