bug#71853: 29.4; `kill-compilation` does not kill compilation process on Windows

bug#71853: 29.4; `kill-compilation` does not kill compilation process on Windows

[Tze Chian Kam]

[-- Attachment #1: Type: text/plain, Size: 3754 bytes --]

Steps to reproduce:
1) Open Emacs with `-q`.
2) Run a trivial file with an infinite loop with `M-x compile`

Expected outcome:
Should be able to kill the process with `M-x kill-compilation` or
`C-c C-k`.

Actual outcome:
`C-c C-k` is ignored and `M-x kill-compilation` is ran but does not
stop the process.

For now, I have a workaround to advice `compile` to interactive mode
(comint) and killing the process with `C-c C-\`. Is this a Windows
problem or my setup?

In GNU Emacs 29.4 (build 2, x86_64-w64-mingw32) of 2024-06-24 built on
 fv-az1388-367
Windowing system distributor 'Microsoft Corp.', version 10.0.19045
System Description: Microsoft Windows 10 Pro (v10.0.2009.19045.4529)

Configured using:
 'configure --prefix=/mingw64 --host=x86_64-w64-mingw32
 --build=x86_64-w64-mingw32 --with-modules --without-dbus
 --without-compress-install --with-tree-sitter
 --with-native-compilation=aot 'CFLAGS=-march=nocona -msahf
 -mtune=generic -O2 -pipe -fstack-protector-strong
 -fno-optimize-sibling-calls -Wno-error=implicit-function-declaration'
 CPPFLAGS=-D__USE_MINGW_ANSI_STDIO=1 'LDFLAGS= -lpthread''

Configured features:
ACL GIF GMP GNUTLS HARFBUZZ JPEG JSON LIBXML2 MODULES NATIVE_COMP NOTIFY
W32NOTIFY PDUMPER PNG RSVG SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XPM ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: cp1252

Major mode: Python

Minor modes in effect:
  shell-dirtrack-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  line-number-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068
epg-config gnus-util mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils time-date files-x shell pcomplete compile
text-property-search python project byte-opt pcase treesit comint
ansi-osc ring cl-loaddefs comp comp-cstr warnings icons subr-x rx cl-seq
cl-macs gv cl-extra help-mode bytecomp byte-compile cl-lib ansi-color
rmc iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook
vc-hooks lisp-float-type elisp-mode mwheel dos-w32 ls-lisp disp-table
term/w32-win w32-win w32-vars term/common-win tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads w32notify w32 multi-tty
make-network-process native-compile emacs)

Memory information:
((conses 16 1087889 397416)
 (symbols 48 8942 4)
 (strings 32 27579 6087)
 (string-bytes 1 2338937)
 (vectors 16 20075)
 (vector-slots 8 394227 86836)
 (floats 8 42 93)
 (intervals 56 490863 319)
 (buffers 984 13))

[-- Attachment #2: Type: text/html, Size: 4167 bytes --]

bug#71853: 29.4; `kill-compilation` does not kill compilation process on Windows

[Eli Zaretskii]

tags 71853 moreinfo
thanks

> From: Tze Chian Kam <tze.chian.kam@gmail.com>
> Date: Sun, 30 Jun 2024 12:57:11 +1000
> 
> Steps to reproduce:
> 1) Open Emacs with `-q`.
> 2) Run a trivial file with an infinite loop with `M-x compile`

Please show the exact file you used as the compilation command,
because I cannot reproduce this with a few programs I tried, see
below.

> Expected outcome:
> Should be able to kill the process with `M-x kill-compilation` or
> `C-c C-k`.
> 
> Actual outcome:
> `C-c C-k` is ignored and `M-x kill-compilation` is ran but does not
> stop the process.

I tried this with several commands and it worked for me with all of
them.  Here are the commands I tried:

  . sleep 20
  . ping -t SOME-EXISTING-SITE
  . a batch file which does this:

     @echo off
     :again
     ping -n 1 SOME-EXISTING-SITE
     sleep 60s
     goto again

In all three cases, I get the same expected result in the
*compilation* buffer:

  Compilation interrupt at Sun Jun 30 11:58:49, duration 4.44 s

(with the time and the "duration" values changing as appropriate).

So I suspect the problem is with some specific command/program or a
group of programs that behave in a specific way.  Thus the request to
show which program you used in your case.

(Just to be sure: you typed "C-c C-k" from the *compilation* buffer,
yes?  If you want to interrupt the compilation process from another
buffer, you need to invoke kill-compilation by name, via M-x.)

> For now, I have a workaround to advice `compile` to interactive mode
> (comint) and killing the process with `C-c C-\`. Is this a Windows
> problem or my setup?

Not clear yet; more info is needed.

bug#71853: 29.4; `kill-compilation` does not kill compilation process on Windows

[Eli Zaretskii]

[Please use Reply All to reply, to keep the bug tracker CC'ed.]

> From: Tze Chian Kam <tze.chian.kam@gmail.com>
> Date: Mon, 1 Jul 2024 01:58:30 +1000
> 
> > From: Eli Zaretskii
> > Date: Sun, 30 Jun 2024 12:07:06 +0300
> > Please show the exact file you used as the compilation command,
> > because I cannot reproduce this with a few programs I tried, see
> > below.
> 
> Sorry, I used a Python file:
> ```
> import time
> 
> while True:
>     print("active")
>     sleep(1)
> ```

And how exactly did you invoke this?  Please show the complete command
you typed at the prompt of "M-x compile", because trying to reproduce
this (see below) I could't.

Also, can you interrupt the same program if you run it from the
Windows command prompt window and then type Ctrl-C?

I tried to run this program (without knowing how exactly did you do
that).  Here's what I did:

  . saved this program to a file loop.py
  . in "emacs -Q" typed the Emacs command

     M-x compile RET python loop.py RET

I then got an error:

   python loop.py
   active
   Traceback (most recent call last):
     File "loop.py", line 5, in <module>
       sleep(1)
   NameError: name 'sleep' is not defined

   Compilation exited abnormally with code 1 at Sun Jun 30 20:47:35, duration 0.12 s

I then modified the program as follows:

    import time

    while True:
	print("active")
	time.sleep(1)

and ran the same compilation command again, then typed C-c C-k into
the compilation buffer.  The result:

   python loop.py
   active
   active
   active
   active
   active
   Traceback (most recent call last):
     File "loop.py", line 5, in <module>
       time.sleep(1)
   KeyboardInterrupt

   Compilation interrupt at Sun Jun 30 20:49:10, duration 4.37 s

which is what I would expect.

My Python is version 3.4.4, for native MS-Windows, installed from
python.org.

So bottom line: it works for me, even with your test program.  I'm
puzzled why it doesn't work for you.

bug#71853: 29.4; `kill-compilation` does not kill compilation process on Windows

[Tze Chian Kam]

> From: Eli Zaretskii
> Date: Sun, 30 Jun 2024 20:53:34 +0300
>
> > From: Tze Chian Kam <tze.chian.kam@gmail.com>
> > Date: Mon, 1 Jul 2024 01:58:30 +1000
> >
> > > From: Eli Zaretskii
> > > Date: Sun, 30 Jun 2024 12:07:06 +0300
> > > Please show the exact file you used as the compilation command,
> > > because I cannot reproduce this with a few programs I tried, see
> > > below.
> >
> > Sorry, I used a Python file:
> > ```
> > import time
> >
> > while True:
> >     print("active")
> >     sleep(1)
> > ```
>
> And how exactly did you invoke this?  Please show the complete
> command you typed at the prompt of "M-x compile", because trying
> to reproduce this (see below) I could't.

I did "M-x compile RET python loop.py RET". Also, when running this
program, it does not output anything in the *compilation* buffer ("active"
is not printed every second).

> Also, can you interrupt the same program if you run it from the
> Windows command prompt window and then type Ctrl-C?

Yes.

> I tried to run this program (without knowing how exactly did you do
> that).  Here's what I did:
>
>   . saved this program to a file loop.py
>   . in "emacs -Q" typed the Emacs command
>
>      M-x compile RET python loop.py RET
>
> I then got an error:
>
>    python loop.py
>    active
>    Traceback (most recent call last):
>      File "loop.py", line 5, in <module>
>        sleep(1)
>    NameError: name 'sleep' is not defined
>
>    Compilation exited abnormally with code 1 at Sun Jun 30
> 20:47:35, duration 0.12 s

Sorry for the wrong program.

On Mon, 1 Jul 2024 at 03:53, Eli Zaretskii <eliz@gnu.org> wrote:
>
> [Please use Reply All to reply, to keep the bug tracker CC'ed.]
>
> > From: Tze Chian Kam <tze.chian.kam@gmail.com>
> > Date: Mon, 1 Jul 2024 01:58:30 +1000
> >
> > > From: Eli Zaretskii
> > > Date: Sun, 30 Jun 2024 12:07:06 +0300
> > > Please show the exact file you used as the compilation command,
> > > because I cannot reproduce this with a few programs I tried, see
> > > below.
> >
> > Sorry, I used a Python file:
> > ```
> > import time
> >
> > while True:
> >     print("active")
> >     sleep(1)
> > ```
>
> And how exactly did you invoke this?  Please show the complete command
> you typed at the prompt of "M-x compile", because trying to reproduce
> this (see below) I could't.
>
> Also, can you interrupt the same program if you run it from the
> Windows command prompt window and then type Ctrl-C?
>
> I tried to run this program (without knowing how exactly did you do
> that).  Here's what I did:
>
>   . saved this program to a file loop.py
>   . in "emacs -Q" typed the Emacs command
>
>      M-x compile RET python loop.py RET
>
> I then got an error:
>
>    python loop.py
>    active
>    Traceback (most recent call last):
>      File "loop.py", line 5, in <module>
>        sleep(1)
>    NameError: name 'sleep' is not defined
>
>    Compilation exited abnormally with code 1 at Sun Jun 30 20:47:35, duration 0.12 s
>
> I then modified the program as follows:
>
>     import time
>
>     while True:
>         print("active")
>         time.sleep(1)
>
> and ran the same compilation command again, then typed C-c C-k into
> the compilation buffer.  The result:
>
>    python loop.py
>    active
>    active
>    active
>    active
>    active
>    Traceback (most recent call last):
>      File "loop.py", line 5, in <module>
>        time.sleep(1)
>    KeyboardInterrupt
>
>    Compilation interrupt at Sun Jun 30 20:49:10, duration 4.37 s
>
> which is what I would expect.
>
> My Python is version 3.4.4, for native MS-Windows, installed from
> python.org.
>
> So bottom line: it works for me, even with your test program.  I'm
> puzzled why it doesn't work for you.

bug#71853: 29.4; `kill-compilation` does not kill compilation process on Windows

[Eli Zaretskii]

> From: Tze Chian Kam <tze.chian.kam@gmail.com>
> Date: Mon, 1 Jul 2024 12:53:51 +1000
> Cc: 71853@debbugs.gnu.org
> 
> > > Sorry, I used a Python file:
> > > ```
> > > import time
> > >
> > > while True:
> > >     print("active")
> > >     sleep(1)
> > > ```
> >
> > And how exactly did you invoke this?  Please show the complete
> > command you typed at the prompt of "M-x compile", because trying
> > to reproduce this (see below) I could't.
> 
> I did "M-x compile RET python loop.py RET". Also, when running this
> program, it does not output anything in the *compilation* buffer ("active"
> is not printed every second).

The fact that it doesn't print "active" is already a sign of some
problem.

Where did you download your Python from?  Is it a native Windows
executable, or something else, like Cygwin or MSYS2 build of Python?

bug#71853: 29.4; `kill-compilation` does not kill compilation process on Windows

[Tze Chian Kam]

> From: Eli Zaretskii
> Date: Mon, 01 Jul 2024 14:27:09 +0300
>
> > From: Tze Chian Kam <tze.chian.kam@gmail.com>
> > Date: Mon, 1 Jul 2024 12:53:51 +1000
> > Cc: 71853@debbugs.gnu.org
> >
> > > > Sorry, I used a Python file:
> > > > ```
> > > > import time
> > > >
> > > > while True:
> > > >     print("active")
> > > >     sleep(1)
> > > > ```
> > >
> > > And how exactly did you invoke this?  Please show the complete
> > > command you typed at the prompt of "M-x compile", because trying
> > > to reproduce this (see below) I could't.
> >
> > I did "M-x compile RET python loop.py RET". Also, when running this
> > program, it does not output anything in the *compilation* buffer ("active"
> > is not printed every second).
>
> The fact that it doesn't print "active" is already a sign of some
> problem.
>
> Where did you download your Python from?  Is it a native Windows
> executable, or something else, like Cygwin or MSYS2 build of Python?

It is a MSYS2 build of Python.

I just tested with Emacs in my global path (so I can launch Emacs from
Powershell/Command Prompt) and it "C-c C-k' works (using native
Windows Python) but I still can't see the prints before killing the process.

bug#71853: 29.4; `kill-compilation` does not kill compilation process on Windows

[Tze Chian Kam]

> From: Tze Chian Kam
> Date: Tue, 2 Jul 2024 16:26:32 +1000
>
> > From: Eli Zaretskii
> > Date: Mon, 01 Jul 2024 14:27:09 +0300
> >
> > > From: Tze Chian Kam <tze.chian.kam@gmail.com>
> > > Date: Mon, 1 Jul 2024 12:53:51 +1000
> > > Cc: 71853@debbugs.gnu.org
> > >
> > > > > Sorry, I used a Python file:
> > > > > ```
> > > > > import time
> > > > >
> > > > > while True:
> > > > >     print("active")
> > > > >     sleep(1)
> > > > > ```
> > > >
> > > > And how exactly did you invoke this?  Please show the complete
> > > > command you typed at the prompt of "M-x compile", because trying
> > > > to reproduce this (see below) I could't.
> > >
> > > I did "M-x compile RET python loop.py RET". Also, when running this
> > > program, it does not output anything in the *compilation* buffer ("active"
> > > is not printed every second).
> >
> > The fact that it doesn't print "active" is already a sign of some
> > problem.
> >
> > Where did you download your Python from?  Is it a native Windows
> > executable, or something else, like Cygwin or MSYS2 build of Python?
>
> It is a MSYS2 build of Python.
>
> I just tested with Emacs in my global path (so I can launch Emacs from
> Powershell/Command Prompt) and it "C-c C-k' works (using native
> Windows Python) but I still can't see the prints before killing the process.

I can see the prints if I do "print("active", flush=True)". Does that mean
there is a flushing problem on my Emacs?

bug#71853: 29.4; `kill-compilation` does not kill compilation process on Windows

[Eli Zaretskii]

> From: Tze Chian Kam <tze.chian.kam@gmail.com>
> Date: Tue, 2 Jul 2024 16:36:38 +1000
> Cc: 71853@debbugs.gnu.org
> 
> > From: Tze Chian Kam
> > Date: Tue, 2 Jul 2024 16:26:32 +1000
> >
> > > From: Eli Zaretskii
> > > Date: Mon, 01 Jul 2024 14:27:09 +0300
> > >
> > > > From: Tze Chian Kam <tze.chian.kam@gmail.com>
> > > > Date: Mon, 1 Jul 2024 12:53:51 +1000
> > > > Cc: 71853@debbugs.gnu.org
> > > >
> > > > > > Sorry, I used a Python file:
> > > > > > ```
> > > > > > import time
> > > > > >
> > > > > > while True:
> > > > > >     print("active")
> > > > > >     sleep(1)
> > > > > > ```
> > > > >
> > > > > And how exactly did you invoke this?  Please show the complete
> > > > > command you typed at the prompt of "M-x compile", because trying
> > > > > to reproduce this (see below) I could't.
> > > >
> > > > I did "M-x compile RET python loop.py RET". Also, when running this
> > > > program, it does not output anything in the *compilation* buffer ("active"
> > > > is not printed every second).
> > >
> > > The fact that it doesn't print "active" is already a sign of some
> > > problem.
> > >
> > > Where did you download your Python from?  Is it a native Windows
> > > executable, or something else, like Cygwin or MSYS2 build of Python?
> >
> > It is a MSYS2 build of Python.
> >
> > I just tested with Emacs in my global path (so I can launch Emacs from
> > Powershell/Command Prompt) and it "C-c C-k' works (using native
> > Windows Python) but I still can't see the prints before killing the process.
> 
> I can see the prints if I do "print("active", flush=True)". Does that mean
> there is a flushing problem on my Emacs?

Something like that, yes.  But I don't understand why it happens for
you with "emacs -Q" and the native Windows Python; it doesn't happen
for me.

bug#71853: 29.4; `kill-compilation` does not kill compilation process on Windows

[Eli Zaretskii]

> From: Tze Chian Kam <tze.chian.kam@gmail.com>
> Date: Tue, 2 Jul 2024 16:26:32 +1000
> Cc: 71853@debbugs.gnu.org
> 
> > From: Eli Zaretskii
> > Date: Mon, 01 Jul 2024 14:27:09 +0300
> >
> > > From: Tze Chian Kam <tze.chian.kam@gmail.com>
> > > Date: Mon, 1 Jul 2024 12:53:51 +1000
> > > Cc: 71853@debbugs.gnu.org
> > >
> > > > > Sorry, I used a Python file:
> > > > > ```
> > > > > import time
> > > > >
> > > > > while True:
> > > > >     print("active")
> > > > >     sleep(1)
> > > > > ```
> > > >
> > > > And how exactly did you invoke this?  Please show the complete
> > > > command you typed at the prompt of "M-x compile", because trying
> > > > to reproduce this (see below) I could't.
> > >
> > > I did "M-x compile RET python loop.py RET". Also, when running this
> > > program, it does not output anything in the *compilation* buffer ("active"
> > > is not printed every second).
> >
> > The fact that it doesn't print "active" is already a sign of some
> > problem.
> >
> > Where did you download your Python from?  Is it a native Windows
> > executable, or something else, like Cygwin or MSYS2 build of Python?
> 
> It is a MSYS2 build of Python.

So it's not a native Windows executable, I think, and this could well
explain what you see.  What does typing the below display?

  M-: (w32-application-type (executable-find "python")) RET

Also, does setting w32-start-process-share-console to a non-nil value
help with interrupting the MSYS2 Python?

> I just tested with Emacs in my global path (so I can launch Emacs from
> Powershell/Command Prompt) and it "C-c C-k' works (using native
> Windows Python) but I still can't see the prints before killing the process.

Some kind of buffering problem, I guess?  Try invoking "python -u" to
get unbuffered stdout.

bug#71853: 29.4; `kill-compilation` does not kill compilation process on Windows

[Tze Chian Kam]

> From: Eli Zaretskii
> Date: Tue, 02 Jul 2024 15:41:34 +0300
>
> > From: Tze Chian Kam <tze.chian.kam@gmail.com>
> > Date: Tue, 2 Jul 2024 16:26:32 +1000
> > Cc: 71853@debbugs.gnu.org
> >
> > > From: Eli Zaretskii
> > > Date: Mon, 01 Jul 2024 14:27:09 +0300
> > >
> > > > From: Tze Chian Kam <tze.chian.kam@gmail.com>
> > > > Date: Mon, 1 Jul 2024 12:53:51 +1000
> > > > Cc: 71853@debbugs.gnu.org
> > > >
> > > > > > Sorry, I used a Python file:
> > > > > > ```
> > > > > > import time
> > > > > >
> > > > > > while True:
> > > > > >     print("active")
> > > > > >     sleep(1)
> > > > > > ```
> > > > >
> > > > > And how exactly did you invoke this?  Please show the complete
> > > > > command you typed at the prompt of "M-x compile", because trying
> > > > > to reproduce this (see below) I could't.
> > > >
> > > > I did "M-x compile RET python loop.py RET". Also, when running this
> > > > program, it does not output anything in the *compilation* buffer ("active"
> > > > is not printed every second).
> > >
> > > The fact that it doesn't print "active" is already a sign of some
> > > problem.
> > >
> > > Where did you download your Python from?  Is it a native Windows
> > > executable, or something else, like Cygwin or MSYS2 build of Python?
> >
> > It is a MSYS2 build of Python.
>
> So it's not a native Windows executable, I think, and this could well
> explain what you see.  What does typing the below display?
>
>   M-: (w32-application-type (executable-find "python")) RET

I get "w32-native".

> Also, does setting w32-start-process-share-console to a non-nil value
> help with interrupting the MSYS2 Python?

Yes, it does.

> > I just tested with Emacs in my global path (so I can launch Emacs from
> > Powershell/Command Prompt) and it "C-c C-k' works (using native
> > Windows Python) but I still can't see the prints before killing the process.
>
> Some kind of buffering problem, I guess?  Try invoking "python -u" to
> get unbuffered stdout.

This will work. However, I tested on another C program and the problem
still occurs, meaning that my Emacs is buffering everything for some
reason.

Here is my test file:
```
#include <stdio.h>
#include <unistd.h>

int main() {
  for (int i = 0; i < 5; ++i) {
    printf("%d\n", i);
    sleep(1);
  }
  return 0;
}
```

bug#71853: 29.4; `kill-compilation` does not kill compilation process on Windows

[Eli Zaretskii]

> From: Tze Chian Kam <tze.chian.kam@gmail.com>
> Date: Wed, 3 Jul 2024 13:26:32 +1000
> Cc: 71853@debbugs.gnu.org
> 
> > > It is a MSYS2 build of Python.
> >
> > So it's not a native Windows executable, I think, and this could well
> > explain what you see.  What does typing the below display?
> >
> >   M-: (w32-application-type (executable-find "python")) RET
> 
> I get "w32-native".

I guess our detection of MSYS applications needs some update?  Can you
show the list of DLLs that your MSYS2 python.exe depends on?  If you
have GNU Binutils installed, the following command should show that:

  objdump -x /path/to/python.exe | fgrep "DLL Name"

> > Also, does setting w32-start-process-share-console to a non-nil value
> > help with interrupting the MSYS2 Python?
> 
> Yes, it does.

So I guess that version of Python is incompatible with the default
method of interrupting sub-processes that Emacs on Windows uses.  It
is known that some programs need such a special handling on Windows.

> > Some kind of buffering problem, I guess?  Try invoking "python -u" to
> > get unbuffered stdout.
> 
> This will work. However, I tested on another C program and the problem
> still occurs, meaning that my Emacs is buffering everything for some
> reason.

It isn't Emacs, it's the OS.  Emacs on Windows uses pipes to talk to
sub-processes, and pipes are buffered.  You need to fflush in your
program.  This is a known issue without any general solution.

So, bottom line, I see no bug here, only known limitations of handling
sub-processes on MS-Windows.

bug#71853: 29.4; `kill-compilation` does not kill compilation process on Windows

[Tze Chian Kam]

> From: Eli Zaretskii
> Date: Wed, 03 Jul 2024 14:17:06 +0300
>
> I guess our detection of MSYS applications needs some update?  Can you
> show the list of DLLs that your MSYS2 python.exe depends on?  If you
> have GNU Binutils installed, the following command should show that:
>
>   objdump -x /path/to/python.exe | fgrep "DLL Name"

libpython3.11.dll
KERNEL32.dll
msvcrt.dll

> So, bottom line, I see no bug here, only known limitations of handling
> sub-processes on MS-Windows.

Thanks for your help.

bug#71853: 29.4; `kill-compilation` does not kill compilation process on Windows

[Eli Zaretskii]

> From: Tze Chian Kam <tze.chian.kam@gmail.com>
> Date: Thu, 4 Jul 2024 14:30:15 +1000
> Cc: 71853@debbugs.gnu.org
> 
> > From: Eli Zaretskii
> > Date: Wed, 03 Jul 2024 14:17:06 +0300
> >
> > I guess our detection of MSYS applications needs some update?  Can you
> > show the list of DLLs that your MSYS2 python.exe depends on?  If you
> > have GNU Binutils installed, the following command should show that:
> >
> >   objdump -x /path/to/python.exe | fgrep "DLL Name"
> 
> libpython3.11.dll
> KERNEL32.dll
> msvcrt.dll

If this is the MSYS2 Python, the one you cannot interrupt, I guess
some recent change in Python for Windows causes this problem.  Because
my Python is older and I don't have this problem.