* bug#70544: 30.0.50; The primitive-function "call-process-region" returns "internal error" and causes high cpu usage on win10
@ 2024-04-23 18:02 leuven65
2024-04-24 6:07 ` Eli Zaretskii
0 siblings, 1 reply; 6+ messages in thread
From: leuven65 @ 2024-04-23 18:02 UTC (permalink / raw)
To: 70544
[-- Attachment #1: Type: text/plain, Size: 540 bytes --]
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")
[-- Attachment #2: Type: text/html, Size: 760 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#70544: 30.0.50; The primitive-function "call-process-region" returns "internal error" and causes high cpu usage on win10
2024-04-23 18:02 bug#70544: 30.0.50; The primitive-function "call-process-region" returns "internal error" and causes high cpu usage on win10 leuven65
@ 2024-04-24 6:07 ` Eli Zaretskii
2024-04-24 8:12 ` leuven65
0 siblings, 1 reply; 6+ messages in thread
From: Eli Zaretskii @ 2024-04-24 6:07 UTC (permalink / raw)
To: leuven65; +Cc: 70544
> From: leuven65 <leuven65@gmail.com>
> Date: Tue, 23 Apr 2024 20:02:39 +0200
>
> 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,
I cannot reproduce this. But my Git for Windows is quite old, so
maybe newer versions made some change? What is gitk on your machine?
Is it a gitk.exe program or some kind of script?
> 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")
gitk is a GUI program, so why are you invoking it with
call-process-region? gitk will never read anything from its stdin or
write anything to its stdout. I suggest to invoke gitk from Emacs
like this:
M-! gitk & RET
IOW, add the "&" character at the end of the command line to make the
invocation asynchronous, instead of letting Emacs block until gitk
exits.
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#70544: 30.0.50; The primitive-function "call-process-region" returns "internal error" and causes high cpu usage on win10
2024-04-24 6:07 ` Eli Zaretskii
@ 2024-04-24 8:12 ` leuven65
2024-04-24 8:25 ` Eli Zaretskii
0 siblings, 1 reply; 6+ messages in thread
From: leuven65 @ 2024-04-24 8:12 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 70544
[-- Attachment #1: Type: text/plain, Size: 2885 bytes --]
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
On Wed, Apr 24, 2024 at 8:07 AM Eli Zaretskii <eliz@gnu.org> wrote:
> > From: leuven65 <leuven65@gmail.com>
> > Date: Tue, 23 Apr 2024 20:02:39 +0200
> >
> > 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,
>
> I cannot reproduce this. But my Git for Windows is quite old, so
> maybe newer versions made some change? What is gitk on your machine?
> Is it a gitk.exe program or some kind of script?
>
> > 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")
>
> gitk is a GUI program, so why are you invoking it with
> call-process-region? gitk will never read anything from its stdin or
> write anything to its stdout. I suggest to invoke gitk from Emacs
> like this:
>
> M-! gitk & RET
>
> IOW, add the "&" character at the end of the command line to make the
> invocation asynchronous, instead of letting Emacs block until gitk
> exits.
>
[-- Attachment #2: Type: text/html, Size: 3893 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#70544: 30.0.50; The primitive-function "call-process-region" returns "internal error" and causes high cpu usage on win10
2024-04-24 8:12 ` leuven65
@ 2024-04-24 8:25 ` Eli Zaretskii
2024-05-09 7:16 ` Eli Zaretskii
0 siblings, 1 reply; 6+ messages in thread
From: Eli Zaretskii @ 2024-04-24 8:25 UTC (permalink / raw)
To: leuven65; +Cc: 70544
> 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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#70544: 30.0.50; The primitive-function "call-process-region" returns "internal error" and causes high cpu usage on win10
2024-04-24 8:25 ` Eli Zaretskii
@ 2024-05-09 7:16 ` Eli Zaretskii
2024-05-25 7:40 ` Eli Zaretskii
0 siblings, 1 reply; 6+ messages in thread
From: Eli Zaretskii @ 2024-05-09 7:16 UTC (permalink / raw)
To: leuven65; +Cc: 70544
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.
> Cc: 70544@debbugs.gnu.org
> Date: Wed, 24 Apr 2024 11:25:15 +0300
> From: 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.
>
>
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#70544: 30.0.50; The primitive-function "call-process-region" returns "internal error" and causes high cpu usage on win10
2024-05-09 7:16 ` Eli Zaretskii
@ 2024-05-25 7:40 ` Eli Zaretskii
0 siblings, 0 replies; 6+ messages in thread
From: Eli Zaretskii @ 2024-05-25 7:40 UTC (permalink / raw)
To: leuven65; +Cc: 70544-done
> Cc: 70544@debbugs.gnu.org
> Date: Thu, 09 May 2024 10:16:12 +0300
> From: Eli Zaretskii <eliz@gnu.org>
>
> 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: 70544@debbugs.gnu.org
> > Date: Wed, 24 Apr 2024 11:25:15 +0300
> > From: 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.
> >
> >
> >
> >
>
>
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2024-05-25 7:40 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-04-23 18:02 bug#70544: 30.0.50; The primitive-function "call-process-region" returns "internal error" and causes high cpu usage on win10 leuven65
2024-04-24 6:07 ` Eli Zaretskii
2024-04-24 8:12 ` leuven65
2024-04-24 8:25 ` Eli Zaretskii
2024-05-09 7:16 ` Eli Zaretskii
2024-05-25 7:40 ` Eli Zaretskii
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.