From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: leuven65 Newsgroups: gmane.emacs.bugs Subject: bug#70544: 30.0.50; The primitive-function "call-process-region" returns "internal error" and causes high cpu usage on win10 Date: Wed, 24 Apr 2024 10:12:10 +0200 Message-ID: References: <86zftj2szq.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000d4d1460616d33a60" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24858"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 70544@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Apr 24 10:13:17 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1rzXki-0006Kq-KW for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 24 Apr 2024 10:13:16 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rzXkW-00063t-V8; Wed, 24 Apr 2024 04:13:04 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rzXkM-000629-Gc for bug-gnu-emacs@gnu.org; Wed, 24 Apr 2024 04:12:58 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rzXkM-0005jG-8b for bug-gnu-emacs@gnu.org; Wed, 24 Apr 2024 04:12:54 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rzXkc-0007F1-Rq for bug-gnu-emacs@gnu.org; Wed, 24 Apr 2024 04:13:10 -0400 X-Loop: help-debbugs@gnu.org Resent-From: leuven65 Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 24 Apr 2024 08:13:10 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 70544 X-GNU-PR-Package: emacs Original-Received: via spool by 70544-submit@debbugs.gnu.org id=B70544.171394637327662 (code B ref 70544); Wed, 24 Apr 2024 08:13:10 +0000 Original-Received: (at 70544) by debbugs.gnu.org; 24 Apr 2024 08:12:53 +0000 Original-Received: from localhost ([127.0.0.1]:57164 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rzXkI-0007Bf-Ez for submit@debbugs.gnu.org; Wed, 24 Apr 2024 04:12:52 -0400 Original-Received: from mail-oa1-x34.google.com ([2001:4860:4864:20::34]:49263) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rzXkC-0007A7-IX for 70544@debbugs.gnu.org; Wed, 24 Apr 2024 04:12:48 -0400 Original-Received: by mail-oa1-x34.google.com with SMTP id 586e51a60fabf-2348a5d1584so2744725fac.2 for <70544@debbugs.gnu.org>; Wed, 24 Apr 2024 01:12:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1713946341; x=1714551141; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=o6gK10eK5An0BlkIJaR0hwH7uakRAxHVxkNl/+iqCCM=; b=aZH48WDBxO5OocciEFRgxsUfoA1gmUv8YyS0j0xJB702Ru/pEfQbXK5GEDXPYPFG6f i17BssEDmq5BxBFgOWiEE76ZibjCdIW8+B3ITUqCmFj4HN3pPqifCYh4iqD9DlX3tqov T+BaBh8LP9ahsiPDJySAIDwc8Xl1rpwmtyrsezAHbz1lciHEXyNeb4+jiRFO+GiagvRn RCL6ecOzDGwPPQiQU8nKNf+RfGcdAcwJJ/WylrxDBcfSB5e9yLB+Zs3hMHsYsxBkFg1D KlKt6rgVzyyHNsbNBYCIc7GYQ+FOY1fH2ZeSEFb7NWeaYpMCa8SQ3VdUjUhkoh4RNTon k5sQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713946341; x=1714551141; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=o6gK10eK5An0BlkIJaR0hwH7uakRAxHVxkNl/+iqCCM=; b=eHby5G5lbh4B95oyGEfQbp0xre69mZ0YrexSrJQ4kiv3Kl4EmbAg4g8yK58Y4H5fE2 v/I8AU4Rm30fL0kelZZF+OBtpcEB+A1Yfepn5+Wv3fiTE/ZUr/DLaI03aaiP/Er/dXjs m7UAWHg0pUSRqUTqsJC0ixKGx3495gZ23Psn0zdWqVJjIAyBcj5qFK9qYXNMX2fchRW3 gCYQoLG/4ddaYWlqVidMeQf42y+GboPbsQkWjjxNelXt26tREOUmxRIeN0wyYcBm/TVk gy/YVzDCYSQNMXcoki114i1cwr5YsyaQuh8kiZD5Zov+PXSr2Z1JFrV0vqJqLsf2bK0L CtEw== X-Gm-Message-State: AOJu0YzAu9VS8NNXsvviBogolAHvc0Ddyeys/sTQwZoCzRtKnt3QpQfD sZdVJDKuTBdyQyTOYyDa+rJxEDPfrzpGOAly0ZUNfV6W9d5OP52HwmwBCJrANd87tWS8PSZnKGO 2hEd6pdFexhKprQUGlRfqeB25Fpg= X-Google-Smtp-Source: AGHT+IHcu4DXiLeC18OoOxYdLwZIDy0EUulGo9NRIMx503WGJVLZGX0u+ROaT/DTjqwMOFesTHM820h3Hr58JnwcGDc= X-Received: by 2002:a05:6870:b418:b0:221:1c2f:23ee with SMTP id x24-20020a056870b41800b002211c2f23eemr1845435oap.22.1713946341197; Wed, 24 Apr 2024 01:12:21 -0700 (PDT) In-Reply-To: <86zftj2szq.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:283910 Archived-At: --000000000000d4d1460616d33a60 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 # nil "-c" "gitk.exe") apply(call-process-region 324 324 "cmdproxy.exe" (nil # nil "-c" "gitk.exe")) call-shell-region(324 324 "gitk.exe" nil #= ) 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=E2=80=AFAM Eli Zaretskii wrote: > > From: leuven65 > > 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. > --000000000000d4d1460616d33a60 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 ha= ng 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 u= sage of emacs is very high
forever. As I built emacs without debug infor= mation, what I can see so far is that most of time seems to be spent on
= "MsgWaitForMultipleObjects".

I use "shell-command&quo= t; (M-!) to run "gitk.exe", the correct behavior is to run "= gitk" and block emacs, or exit with
error, in my case, it prints ou= t 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--ent= ering a function:
,* call-process-region(324 324 "cmdproxy.exe"= ; nil #<buffer *Shell Command Output*> nil "-c" "gitk.= exe")
=C2=A0 apply(call-process-region 324 324 "cmdproxy.exe&q= uot; (nil #<buffer *Shell Command Output*> nil "-c" "g= itk.exe"))
=C2=A0 call-shell-region(324 324 "gitk.exe" ni= l #<buffer *Shell Command Output*>)
=C2=A0 shell-command-on-region= (324 324 "gitk.exe" nil nil nil)
=C2=A0 shell-command("gi= tk.exe" nil nil)
=C2=A0 funcall-interactively(shell-command "g= itk.exe" nil nil)
=C2=A0 command-execute(shell-command)
#+end_qu= ote

On Wed, Apr 24, 2024 at 8:07=E2=80=AFAM 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&qu= ot; 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.=C2=A0 But my Git for Windows is quite old, so
maybe newer versions made some change?=C2=A0 What is gitk on your machine?<= br> 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)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 "cmdproxy.exe"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 t
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 t
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 nil
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 "-c"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 "gitk")

gitk is a GUI program, so why are you invoking it with
call-process-region?=C2=A0 gitk will never read anything from its stdin or<= br> write anything to its stdout.=C2=A0 I suggest to invoke gitk from Emacs
like this:

=C2=A0 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.
--000000000000d4d1460616d33a60--