GNU logs - #15983, boring messages

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#15983: 24.3; Emacs Not Killing Child Process
Resent-From: sjm@HIDDEN
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 27 Nov 2013 17:50:02 +0000
Resent-Message-ID: <handler.15983.B.138557458832406 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 15983 <at> debbugs.gnu.org
From: sjm@HIDDEN
Date: Wed, 27 Nov 2013 17:47:38 +0000
Message-ID: <87zjop3fet.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

I'm using nrepl.el for Clojure development and am having trouble with
residual Java processes when quitting nrepl.el.

The process tree that gets spawned looks like this:

emacs.exe
|_ cmdproxy.exe
   |_ cmd.exe
      |_ java.exe
         |_ java.exe

The problem is that after nrepl-quit is called, only the parent java.exe
process is killed and I'm left with an orphaned java.exe that I have to
kill manually.

The code that does the killing looks like this:

(defun nrepl--close-buffer (buffer)
  "Close the nrepl BUFFER."
  (when (get-buffer-process buffer)
    (delete-process (get-buffer-process buffer)))
  (when (get-buffer buffer)
    (kill-buffer buffer)))

The documentation section "37.5 Deleting Processes" says that child
processes get killed but this doesn't seem to be happening for some reason.

I've spoken with the main developer of nrepl.el and he seems to think it
might be a bug in Emacs.

In GNU Emacs 24.3.1 (i386-mingw-nt6.1.7601)
 of 2013-03-17 on MARVIN
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --with-gcc (4.7) --cflags
 -ID:/devel/emacs/libs/libXpm-3.5.8/include
 -ID:/devel/emacs/libs/libXpm-3.5.8/src
 -ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include
 -ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include
 -ID:/devel/emacs/libs/giflib-4.1.4-1/include
 -ID:/devel/emacs/libs/jpeg-6b-4/include
 -ID:/devel/emacs/libs/tiff-3.8.2-1/include
 -ID:/devel/emacs/libs/gnutls-3.0.9/include
 -ID:/devel/emacs/libs/libiconv-1.13.1-1-dev/include
 -ID:/devel/emacs/libs/libxml2-2.7.8/include/libxml2'

Important settings:
  value of $LANG: ENG
  locale-coding-system: cp1252
  default enable-multibyte-characters: t

Major mode: Emacs-Lisp

Minor modes in effect:
  paredit-mode: t
  shell-dirtrack-mode: t
  global-rainbow-delimiters-mode: t
  rainbow-delimiters-mode: t
  show-paren-mode: t
  desktop-save-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
M-x n r e <return> <help-echo> <down-mouse-1> <mouse-1> 
M-x <right> <return> y C-x o C-x k <return> C-s s m 
t p <return> <down> <home> M-x b u g <right> <right> 
<right> <right> <right> <backspace> <backspace> <backspace> 
r e p o r t - <return> E m a c s SPC n o t SPC k i 
l l i n g SPC c h i l d SPC p r o c e s s <return> 
<down-mouse-1> <mouse-1> C-x k <return> y e s <return> 
C-x 1 <prior> <up> <up> <up> <up> <up> <up> <up> <up> 
<up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <return> 
<S-insert> C-x C-s <home> <next> <prior> <up> <up> 
<up> <up> <up> <up> <up> <up> <up> M-x c u s t o m 
<return> e m a <tab> <tab> <backspace> <backspace> 
<backspace> <backspace> <backspace> <backspace> s m 
t <tab> <return> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> <down> <next> <prior> q M-x <return> e m a <tab> 
<backspace> <backspace> <backspace> <backspace> <backspace> 
C-g <up> <up> <up> <up> <up> <up> <up> <up> <end> <left> 
<left> <backspace> <backspace> <backspace> <backspace> 
<backspace> <backspace> <backspace> <backspace> <backspace> 
<backspace> <backspace> <backspace> <backspace> <backspace> 
<backspace> <backspace> <backspace> <backspace> s j 
m @ s j m . i o C-x C-s <home> C-SPC <down> C-w <down> 
<S-insert> C-x C-s <up> <end> C-x C-e M-x <right> <return> 
E m a c s SPC <help-echo> <help-echo> <down-mouse-1> 
<mouse-1> <help-echo> <help-echo> <help-echo> <end> 
<C-backspace> <S-insert> <return> C-x k <return> y 
e s <return> C-x 1 M-x <return>

Recent messages:
Checking 70 files in c:/Users/Simon/Desktop/Programs/emacs-24.3/lisp/erc...
Checking 48 files in c:/Users/Simon/Desktop/Programs/emacs-24.3/lisp/emulation...
Checking 147 files in c:/Users/Simon/Desktop/Programs/emacs-24.3/lisp/emacs-lisp...
Checking 24 files in c:/Users/Simon/Desktop/Programs/emacs-24.3/lisp/cedet...
Checking 57 files in c:/Users/Simon/Desktop/Programs/emacs-24.3/lisp/calendar...
Checking 87 files in c:/Users/Simon/Desktop/Programs/emacs-24.3/lisp/calc...
Checking 77 files in c:/Users/Simon/Desktop/Programs/emacs-24.3/lisp/obsolete...
Checking 2 files in c:/Users/Simon/Desktop/Programs/emacs-24.3/leim...
Checking for load-path shadows...done
Mark activated

Load-path shadows:
~/.emacs.d/bs hides c:/Users/Simon/Desktop/Programs/emacs-24.3/lisp/bs

Features:
(smtpmail cus-edit cus-start cus-load wid-edit help-mode shadow sort
mail-extr emacsbug message rfc822 mml mml-sec mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail
rfc2047 rfc2045 ietf-drums mail-utils misearch multi-isearch lisp-mnt
network-stream starttls tls smex dired org-wl org-w3m org-vm org-rmail
org-mhe org-mew org-irc org-jsinfo org-infojs org-html org-exp ob-exp
org-exp-blocks org-agenda org-info org-gnus org-docview org-bibtex
bibtex org-bbdb org warnings ob-tangle ob-ref ob-lob ob-table
org-footnote org-src ob-comint ob-keys org-pcomplete org-list org-faces
org-entities org-version ob-emacs-lisp ob org-compat org-macs ob-eval
org-loaddefs cal-menu calendar cal-loaddefs clojure-test-mode nrepl
compile ewoc eldoc arc-mode archive-mode etags pkg-info find-func epl
dash which-func paredit clojure-mode imenu inf-lisp tramp tramp-compat
auth-source eieio byte-opt bytecomp byte-compile cconv gnus-util mm-util
mail-prsvr password-cache tramp-loaddefs cl-macs gv shell pcomplete
format-spec advice help-fns advice-preload cl cl-lib ample-theme edmacro
kmacro rainbow-delimiters paren ido desktop frink-mode comint ansi-color
ring markdown-mode thingatpt noutline outline easy-mmode easymenu
ample-theme-autoloads clojure-test-mode-autoloads
markdown-mode-autoloads nrepl-autoloads clojure-mode-autoloads
paredit-autoloads pkg-info-autoloads epl-autoloads finder-inf
dash-autoloads rainbow-delimiters-autoloads s-autoloads smex-autoloads
package time-date tooltip ediff-hook vc-hooks lisp-float-type mwheel
dos-w32 ls-lisp w32-common-fns disp-table w32-win w32-vars tool-bar dnd
fontset image regexp-opt fringe tabulated-list newcomment lisp-mode
register page menu-bar rfn-eshadow timer select scroll-bar mouse
jit-lock font-lock syntax facemenu font-core frame cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev
minibuffer loaddefs button faces cus-face macroexp files text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process w32 multi-tty
emacs)

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.503 (Entity 5.503)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: sjm@HIDDEN
Subject: bug#15983: Acknowledgement (24.3; Emacs Not Killing Child Process)
Message-ID: <handler.15983.B.138557458832406.ack <at> debbugs.gnu.org>
References: <87zjop3fet.fsf@HIDDEN>
X-Gnu-PR-Message: ack 15983
X-Gnu-PR-Package: emacs
Reply-To: 15983 <at> debbugs.gnu.org
Date: Wed, 27 Nov 2013 17:50:03 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-gnu-emacs@HIDDEN

If you wish to submit further information on this problem, please
send it to 15983 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
15983: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D15983
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#15983: 24.3; Emacs Not Killing Child Process
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 27 Nov 2013 21:03:02 +0000
Resent-Message-ID: <handler.15983.B15983.138558617218813 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: sjm@HIDDEN
Cc: 15983 <at> debbugs.gnu.org
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Date: Wed, 27 Nov 2013 23:02:35 +0200
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <87zjop3fet.fsf@HIDDEN>
Message-id: <8338mha784.fsf@HIDDEN>
References: <87zjop3fet.fsf@HIDDEN>
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

> From: sjm@HIDDEN
> Date: Wed, 27 Nov 2013 17:47:38 +0000
> 
> I'm using nrepl.el for Clojure development and am having trouble with
> residual Java processes when quitting nrepl.el.
> 
> The process tree that gets spawned looks like this:
> 
> emacs.exe
> |_ cmdproxy.exe
>    |_ cmd.exe
>       |_ java.exe
>          |_ java.exe
> 
> The problem is that after nrepl-quit is called, only the parent java.exe
> process is killed and I'm left with an orphaned java.exe that I have to
> kill manually.
> 
> The code that does the killing looks like this:
> 
> (defun nrepl--close-buffer (buffer)
>   "Close the nrepl BUFFER."
>   (when (get-buffer-process buffer)
>     (delete-process (get-buffer-process buffer)))
>   (when (get-buffer buffer)
>     (kill-buffer buffer)))
> 
> The documentation section "37.5 Deleting Processes" says that child
> processes get killed but this doesn't seem to be happening for some reason.
> 
> I've spoken with the main developer of nrepl.el and he seems to think it
> might be a bug in Emacs.

Emacs on Windows can only monitor and kill its immediate subprocesses,
it cannot monitor, let alone kill, any of their descendant processes,
because it has no idea about them.  And the OS doesn't automatically
kill all the processes in the subprocess tree, and there's no way to
send a signal to them all, as on Posix platforms.  If killing the
immediate child process doesn't cause some of its children to exit or
abort, then those grandchildren will be left orphaned.

Why doesn't the child java.exe exit when it parent does?  Can you
arrange for that to happen?  Failing that, I don't think there's a
solution to this problem, sorry.

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#15983: Fw: bug#15983: 24.3; Emacs Not Killing Child Process
Resent-From: Bozhidar Batsov <bozhidar.batsov@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 19 Dec 2013 15:57:02 +0000
Resent-Message-ID: <handler.15983.B15983.13874686147551 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 15983 <at> debbugs.gnu.org
Date: Thu, 19 Dec 2013 17:56:46 +0200
From: Bozhidar Batsov <bozhidar.batsov@HIDDEN>
Message-ID: <D55B149A712C44658EBA327A9B8D664F@HIDDEN>
In-Reply-To: <CAGVACNVfa8bvqHDOavzUzb6mGCxRHPzu2Pbv4Yi-76Ca+B_Rcw@HIDDEN>
References: <CAGVACNVfa8bvqHDOavzUzb6mGCxRHPzu2Pbv4Yi-76Ca+B_Rcw@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="52b3173e_52d7b105_1c26"
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

--52b3173e_52d7b105_1c26
Content-Type: multipart/alternative; boundary="52b3173e_dcdf8f6_1c26"

--52b3173e_dcdf8f6_1c26
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Forwarded message:
> From: Joan Karadimov <joan.karadimov@HIDDEN>
> To: bug-gnu-emacs@HIDDEN
> Cc: sjm@HIDDEN, eliz@HIDDEN, Bozhidar Batsov <bozhidar.batsov@HIDDEN>
> Date: Thursday, December 19, 2013 at 5:44:37 PM
> Subject: bug#15983: 24.3; Emacs Not Killing Child Process
> 
> > Emacs on Windows can only monitor and kill its immediate subprocesses, > it cannot monitor, let alone kill, any of their descendant processes, > because it has no idea about them. And the OS doesn't automatically > kill all the processes in the subprocess tree, and there's no way to > send a signal to them all, as on Posix platforms. If killing the > immediate child process doesn't cause some of its children to exit or > abort, then those grandchildren will be left orphaned. Windows NT does have the concept of parent processes, but an API call wasn't exposed in win32 until XP. I wrote a small patch that uses that and kills all child processes (as long as pid<0). I did some sanity testing and it works. 
> There are a few things that this patch leaves unaddressed: - there is no error handling - there is no OS detection - this will get ugly on Windows 9x and NT4/5.0 - performance: 3 API calls are made for each descendant process. This can be reduced to a total 3 calls (regardless of the child process count)
> 
> I'll fix these (and any other issues) if this fix is of any interest.
> 


--52b3173e_dcdf8f6_1c26
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline


                <div><span style=3D=22color: rgb(160, 160, 168);=22>=46or=
warded message:</span></div>
                <blockquote type=3D=22cite=22 style=3D=22border-left-styl=
e:solid;border-width:1px;margin-left:0px;padding-left:10px;=22>
                    <div>
                        =20
                        <b>=46rom:</b> Joan Karadimov &lt;joan.karadimov=40=
gmail.com&gt;<br>
                        =20
                        =20
                        =20
                        <b>To:</b> bug-gnu-emacs=40gnu.org<br>
                        =20
                        =20
                        <b>Cc:</b> sjm=40sjm.io, eliz=40gnu.org, Bozhidar=
 Batsov &lt;bozhidar.batsov=40gmail.com&gt;<br>
                        =20
                        <b>Date:</b> Thursday, December 19, 2013 at 5:44:=
37 PM<br>
                        <b>Subject:</b> bug=2315983: 24.3; Emacs Not Kill=
ing Child Process<br>
                    </div>
                    =20
                    <br>
                    =20
                    <div><div><div><div dir=3D=22ltr=22><div><pre style=3D=
=22color:rgb(0,0,0)=22>&gt; Emacs on Windows can only monitor and kill it=
s immediate subprocesses,
&gt; it cannot monitor, let alone kill, any of their descendant processes=
,
<span style=3D=22font-family:arial=22>&gt; </span>because it has no idea =
about them.  And the OS doesn't automatically
<span style=3D=22font-family:arial=22>&gt; </span>kill all the processes =
in the subprocess tree, and there's no way to
<span style=3D=22font-family:arial=22>&gt; </span>send a signal to them a=
ll, as on Posix platforms.  If killing the
<span style=3D=22font-family:arial=22>&gt; </span>immediate child process=
 doesn't cause some of its children to exit or
<span style=3D=22font-family:arial=22>&gt; </span>abort, then those grand=
children will be left orphaned.

<font face=3D=22arial=22>Windows NT does have the concept of parent proce=
sses, but an API call wasn't exposed in win32 until XP. I wrote a small p=
atch that uses that and kills all child processes (as long as pid&lt;0). =
I did some sanity testing and it works.</font></pre>
<pre><font face=3D=22arial=22><font color=3D=22=23000000=22>There are a f=
ew things that this patch leaves unaddressed:
</font></font><span style=3D=22color:rgb(34,34,34);font-family:arial=22>-=
 there is no error handling
- there is no OS detection - this will get ugly on Windows 9x and NT4/5.0=

</span><span style=3D=22font-family:arial=22>- performance: 3 API calls a=
re made for each descendant process. This can be reduced to a total 3 cal=
ls (regardless of the child process count)</span></pre></div><div>I'll fi=
x these (and any other issues) if this fix is of any interest.</div>
<div><br></div></div>
</div></div></div>
                </blockquote>
                =20
                <div>
                    <br>
                </div>
            
--52b3173e_dcdf8f6_1c26--

--52b3173e_52d7b105_1c26
Content-Type: application/OCTET-STREAM
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="win32-kill-children"

ZGlmZiAtLWdpdCBzcmMvdzMycHJvYy5jIHNyYy93MzJwcm9jLmMKaW5kZXggMmI1ODNlZi4uMGI4
MmJhMyAxMDA2NDQKLS0tIHNyYy93MzJwcm9jLmMKKysrIHNyYy93MzJwcm9jLmMKQEAgLTQzLDYg
KzQzLDcgQEAgYWxvbmcgd2l0aCBHTlUgRW1hY3MuICBJZiBub3QsIHNlZSA8aHR0cDovL3d3dy5n
bnUub3JnL2xpY2Vuc2VzLz4uICAqLwogI3VuZGVmIGtpbGwKIAogI2luY2x1ZGUgPHdpbmRvd3Mu
aD4KKyNpbmNsdWRlIDx0bGhlbHAzMi5oPgogI2lmZGVmIF9fR05VQ19fCiAvKiBUaGlzIGRlZmlu
aXRpb24gaXMgbWlzc2luZyBmcm9tIG1pbmd3MzIgaGVhZGVycy4gKi8KIGV4dGVybiBCT09MIFdJ
TkFQSSBJc1ZhbGlkTG9jYWxlIChMQ0lELCBEV09SRCk7CkBAIC0yMjcwLDE5ICsyMjcxLDE0IEBA
IGZpbmRfY2hpbGRfY29uc29sZSAoSFdORCBod25kLCBMUEFSQU0gYXJnKQogICByZXR1cm4gVFJV
RTsKIH0KIAotLyogRW11bGF0ZSAna2lsbCcsIGJ1dCBvbmx5IGZvciBvdGhlciBwcm9jZXNzZXMu
ICAqLwotaW50Ci1zeXNfa2lsbCAocGlkX3QgcGlkLCBpbnQgc2lnKQorc3RhdGljIGludAora2ls
bF9wcm9jZXNzIChwaWRfdCBwaWQsIGludCBzaWcpCiB7CiAgIGNoaWxkX3Byb2Nlc3MgKmNwOwog
ICBIQU5ETEUgcHJvY19oYW5kOwogICBpbnQgbmVlZF90b19mcmVlID0gMDsKICAgaW50IHJjID0g
MDsKIAotICAvKiBFYWNoIHByb2Nlc3MgaXMgaW4gaXRzIG93biBwcm9jZXNzIGdyb3VwLiAgKi8K
LSAgaWYgKHBpZCA8IDApCi0gICAgcGlkID0gLXBpZDsKLQogICAvKiBPbmx5IGhhbmRsZSBzaWdu
YWxzIHRoYXQgd2lsbCByZXN1bHQgaW4gdGhlIHByb2Nlc3MgZHlpbmcgKi8KICAgaWYgKHNpZyAh
PSAwCiAgICAgICAmJiBzaWcgIT0gU0lHSU5UICYmIHNpZyAhPSBTSUdLSUxMICYmIHNpZyAhPSBT
SUdRVUlUICYmIHNpZyAhPSBTSUdIVVApCkBAIC0yNDg4LDYgKzI0ODQsMzYgQEAgc3lzX2tpbGwg
KHBpZF90IHBpZCwgaW50IHNpZykKICAgcmV0dXJuIHJjOwogfQogCitzdGF0aWMgaW50CitraWxs
X3Byb2Nlc3NfdHJlZSAoaW50IHBpZCwgaW50IHNpZykKK3sKKyAgUFJPQ0VTU0VOVFJZMzIgcHJv
Y2Vzc19lbnRyeTsKKyAgSEFORExFIHNuYXBzaG90OworCisgIHByb2Nlc3NfZW50cnkuZHdTaXpl
ID0gc2l6ZW9mIChwcm9jZXNzX2VudHJ5KTsKKyAgc25hcHNob3QgPSBDcmVhdGVUb29saGVscDMy
U25hcHNob3QgKFRIMzJDU19TTkFQUFJPQ0VTUywgcGlkKTsKKworICBraWxsX3Byb2Nlc3MgKHBp
ZCwgc2lnKTsKKyAgUHJvY2VzczMyRmlyc3QgKHNuYXBzaG90LCAmcHJvY2Vzc19lbnRyeSk7Cisg
IGRvCisgICAgeworICAgICAgaWYgKHByb2Nlc3NfZW50cnkudGgzMlBhcmVudFByb2Nlc3NJRCA9
PSBwaWQpCisgICAgICAgIGtpbGxfcHJvY2Vzc190cmVlIChwcm9jZXNzX2VudHJ5LnRoMzJQcm9j
ZXNzSUQsIHNpZyk7CisgICAgfSB3aGlsZSAoUHJvY2VzczMyTmV4dCAoc25hcHNob3QsICZwcm9j
ZXNzX2VudHJ5KSk7CisgIENsb3NlSGFuZGxlIChzbmFwc2hvdCk7CisgIHJldHVybiAwOworfQor
CisvKiBFbXVsYXRlICdraWxsJywgYnV0IG9ubHkgZm9yIG90aGVyIHByb2Nlc3Nlcy4gICovCitp
bnQKK3N5c19raWxsIChpbnQgcGlkLCBpbnQgc2lnKQoreworICBpZiAocGlkIDwgMCkKKyAgICBy
ZXR1cm4ga2lsbF9wcm9jZXNzX3RyZWUgKC1waWQsIHNpZyk7CisgIGVsc2UKKyAgICByZXR1cm4g
a2lsbF9wcm9jZXNzIChwaWQsIHNpZyk7Cit9CisKIC8qIFRoZSBmb2xsb3dpbmcgdHdvIHJvdXRp
bmVzIGFyZSB1c2VkIHRvIG1hbmlwdWxhdGUgc3RkaW4sIHN0ZG91dCwgYW5kCiAgICBzdGRlcnIg
b2Ygb3VyIGNoaWxkIHByb2Nlc3Nlcy4KIAo=

--52b3173e_52d7b105_1c26--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#15983: 24.3; Emacs Not Killing Child Process
References: <87zjop3fet.fsf@HIDDEN>
In-Reply-To: <87zjop3fet.fsf@HIDDEN>
Resent-From: Joan Karadimov <joan.karadimov@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 19 Dec 2013 16:53:01 +0000
Resent-Message-ID: <handler.15983.B.138747196213859 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 15983
X-GNU-PR-Package: emacs,w32
X-GNU-PR-Keywords: 
To: 15983 <at> debbugs.gnu.org
Cc: Bozhidar Batsov <bozhidar.batsov@HIDDEN>, eliz@HIDDEN, sjm@HIDDEN
X-Debbugs-Original-To: bug-gnu-emacs@HIDDEN
Received: via spool by submit <at> debbugs.gnu.org id=B.138747196213859
          (code B ref -1); Thu, 19 Dec 2013 16:53:01 +0000
Received: (at submit) by debbugs.gnu.org; 19 Dec 2013 16:52:42 +0000
Received: from localhost ([127.0.0.1]:58833 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1Vtgq2-0003bS-6t
	for submit <at> debbugs.gnu.org; Thu, 19 Dec 2013 11:52:42 -0500
Received: from eggs.gnu.org ([208.118.235.92]:52839)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <joan.karadimov@HIDDEN>) id 1VtfmH-0001bl-AH
 for submit <at> debbugs.gnu.org; Thu, 19 Dec 2013 10:44:46 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <joan.karadimov@HIDDEN>) id 1VtfmF-0002L8-Jl
 for submit <at> debbugs.gnu.org; Thu, 19 Dec 2013 10:44:44 -0500
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM,
 HTML_MESSAGE,T_DKIM_INVALID autolearn=disabled version=3.3.2
Received: from lists.gnu.org ([2001:4830:134:3::11]:53152)
 by eggs.gnu.org with esmtp (Exim 4.71)
 (envelope-from <joan.karadimov@HIDDEN>) id 1VtfmF-0002L0-GV
 for submit <at> debbugs.gnu.org; Thu, 19 Dec 2013 10:44:43 -0500
Received: from eggs.gnu.org ([2001:4830:134:3::10]:54553)
 by lists.gnu.org with esmtp (Exim 4.71)
 (envelope-from <joan.karadimov@HIDDEN>) id 1VtfmD-00076Z-Ta
 for bug-gnu-emacs@HIDDEN; Thu, 19 Dec 2013 10:44:43 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <joan.karadimov@HIDDEN>) id 1VtfmC-0002KP-M2
 for bug-gnu-emacs@HIDDEN; Thu, 19 Dec 2013 10:44:41 -0500
Received: from mail-wi0-x229.google.com ([2a00:1450:400c:c05::229]:48970)
 by eggs.gnu.org with esmtp (Exim 4.71)
 (envelope-from <joan.karadimov@HIDDEN>)
 id 1VtfmC-0002K7-9O; Thu, 19 Dec 2013 10:44:40 -0500
Received: by mail-wi0-f169.google.com with SMTP id hn6so6743611wib.4
 for <multiple recipients>; Thu, 19 Dec 2013 07:44:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=mime-version:date:message-id:subject:from:to:cc:content-type;
 bh=YbIHSZpDCeZ1kSSOjpRKf3lP0n/arVwwPtecrGNReh4=;
 b=IstxtwVkVU3+vXE27MIQ+COItUFDaft4sMF3jThbJ20d4VB1skTIQtD1C7O2BsLi4M
 5RRtljshMKTFIs3E+8jmPYJx+1GzXIcZfXj/ZcIuKro0XKdo2YwMJ2BCn/WvHNLfKctV
 4pM9OpChAgtsYJ/yHoDm7CaCcBeXdJ4pVYf07A5vv3HlfPi8Zhv3pV1Rms1PyK0gxwa2
 AcNDUBmKX0YJiXea29cDQDa0ugg6hMkYpXb+wqG1WDBEC+zOHs+pvxnvvXz5aGp1+TfU
 nh/AgubTFxc8p89kcKO0XXPUf+XhOB8nYDAjdooDuU/tQa9SghaslLEpWQSlRd+xWLWV
 Niww==
MIME-Version: 1.0
X-Received: by 10.194.189.132 with SMTP id gi4mr2044253wjc.5.1387467878428;
 Thu, 19 Dec 2013 07:44:38 -0800 (PST)
Received: by 10.216.127.68 with HTTP; Thu, 19 Dec 2013 07:44:37 -0800 (PST)
Date: Thu, 19 Dec 2013 17:44:37 +0200
Message-ID: <CAGVACNVfa8bvqHDOavzUzb6mGCxRHPzu2Pbv4Yi-76Ca+B_Rcw@HIDDEN>
From: Joan Karadimov <joan.karadimov@HIDDEN>
Content-Type: multipart/mixed; boundary=047d7bb0437408573c04ede50a5c
X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address
 (bad octet value).
X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address
 (bad octet value).
X-Received-From: 2001:4830:134:3::11
X-Spam-Score: -4.0 (----)
X-Mailman-Approved-At: Thu, 19 Dec 2013 11:52:40 -0500
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -4.0 (----)

--047d7bb0437408573c04ede50a5c
Content-Type: multipart/alternative; boundary=047d7bb0437408573804ede50a5a

--047d7bb0437408573804ede50a5a
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

> Emacs on Windows can only monitor and kill its immediate subprocesses,
> it cannot monitor, let alone kill, any of their descendant processes,> be=
cause it has no idea about them.  And the OS doesn't automatically> kill al=
l the processes in the subprocess tree, and there's no way to> send a signa=
l to them all, as on Posix platforms.  If killing the> immediate child proc=
ess doesn't cause some of its children to exit or> abort, then those grandc=
hildren will be left orphaned.
Windows NT does have the concept of parent processes, but an API call
wasn't exposed in win32 until XP. I wrote a small patch that uses that
and kills all child processes (as long as pid<0). I did some sanity
testing and it works.

There are a few things that this patch leaves unaddressed:- there is
no error handling
- there is no OS detection - this will get ugly on Windows 9x and
NT4/5.0- performance: 3 API calls are made for each descendant
process. This can be reduced to a total 3 calls (regardless of the
child process count)

I'll fix these (and any other issues) if this fix is of any interest.

--047d7bb0437408573804ede50a5a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><pre style=3D"color:rgb(0,0,0)">&gt; Emacs on Windows=
 can only monitor and kill its immediate subprocesses,
&gt; it cannot monitor, let alone kill, any of their descendant processes,
<span style=3D"font-family:arial">&gt; </span>because it has no idea about =
them.  And the OS doesn&#39;t automatically
<span style=3D"font-family:arial">&gt; </span>kill all the processes in the=
 subprocess tree, and there&#39;s no way to
<span style=3D"font-family:arial">&gt; </span>send a signal to them all, as=
 on Posix platforms.  If killing the
<span style=3D"font-family:arial">&gt; </span>immediate child process doesn=
&#39;t cause some of its children to exit or
<span style=3D"font-family:arial">&gt; </span>abort, then those grandchildr=
en will be left orphaned.

<font face=3D"arial">Windows NT does have the concept of parent processes, =
but an API call wasn&#39;t exposed in win32 until XP. I wrote a small patch=
 that uses that and kills all child processes (as long as pid&lt;0). I did =
some sanity testing and it works.</font></pre>
<pre><font face=3D"arial"><font color=3D"#000000">There are a few things th=
at this patch leaves unaddressed:
</font></font><span style=3D"color:rgb(34,34,34);font-family:arial">- there=
 is no error handling
- there is no OS detection - this will get ugly on Windows 9x and NT4/5.0
</span><span style=3D"font-family:arial">- performance: 3 API calls are mad=
e for each descendant process. This can be reduced to a total 3 calls (rega=
rdless of the child process count)</span></pre></div><div>I&#39;ll fix thes=
e (and any other issues) if this fix is of any interest.</div>
<div><br></div></div>

--047d7bb0437408573804ede50a5a--
--047d7bb0437408573c04ede50a5c
Content-Type: application/octet-stream; name=win32-kill-children
Content-Disposition: attachment; filename=win32-kill-children
Content-Transfer-Encoding: base64
X-Attachment-Id: f_hpe4lmrl0

ZGlmZiAtLWdpdCBzcmMvdzMycHJvYy5jIHNyYy93MzJwcm9jLmMKaW5kZXggMmI1ODNlZi4uMGI4
MmJhMyAxMDA2NDQKLS0tIHNyYy93MzJwcm9jLmMKKysrIHNyYy93MzJwcm9jLmMKQEAgLTQzLDYg
KzQzLDcgQEAgYWxvbmcgd2l0aCBHTlUgRW1hY3MuICBJZiBub3QsIHNlZSA8aHR0cDovL3d3dy5n
bnUub3JnL2xpY2Vuc2VzLz4uICAqLwogI3VuZGVmIGtpbGwKIAogI2luY2x1ZGUgPHdpbmRvd3Mu
aD4KKyNpbmNsdWRlIDx0bGhlbHAzMi5oPgogI2lmZGVmIF9fR05VQ19fCiAvKiBUaGlzIGRlZmlu
aXRpb24gaXMgbWlzc2luZyBmcm9tIG1pbmd3MzIgaGVhZGVycy4gKi8KIGV4dGVybiBCT09MIFdJ
TkFQSSBJc1ZhbGlkTG9jYWxlIChMQ0lELCBEV09SRCk7CkBAIC0yMjcwLDE5ICsyMjcxLDE0IEBA
IGZpbmRfY2hpbGRfY29uc29sZSAoSFdORCBod25kLCBMUEFSQU0gYXJnKQogICByZXR1cm4gVFJV
RTsKIH0KIAotLyogRW11bGF0ZSAna2lsbCcsIGJ1dCBvbmx5IGZvciBvdGhlciBwcm9jZXNzZXMu
ICAqLwotaW50Ci1zeXNfa2lsbCAocGlkX3QgcGlkLCBpbnQgc2lnKQorc3RhdGljIGludAora2ls
bF9wcm9jZXNzIChwaWRfdCBwaWQsIGludCBzaWcpCiB7CiAgIGNoaWxkX3Byb2Nlc3MgKmNwOwog
ICBIQU5ETEUgcHJvY19oYW5kOwogICBpbnQgbmVlZF90b19mcmVlID0gMDsKICAgaW50IHJjID0g
MDsKIAotICAvKiBFYWNoIHByb2Nlc3MgaXMgaW4gaXRzIG93biBwcm9jZXNzIGdyb3VwLiAgKi8K
LSAgaWYgKHBpZCA8IDApCi0gICAgcGlkID0gLXBpZDsKLQogICAvKiBPbmx5IGhhbmRsZSBzaWdu
YWxzIHRoYXQgd2lsbCByZXN1bHQgaW4gdGhlIHByb2Nlc3MgZHlpbmcgKi8KICAgaWYgKHNpZyAh
PSAwCiAgICAgICAmJiBzaWcgIT0gU0lHSU5UICYmIHNpZyAhPSBTSUdLSUxMICYmIHNpZyAhPSBT
SUdRVUlUICYmIHNpZyAhPSBTSUdIVVApCkBAIC0yNDg4LDYgKzI0ODQsMzYgQEAgc3lzX2tpbGwg
KHBpZF90IHBpZCwgaW50IHNpZykKICAgcmV0dXJuIHJjOwogfQogCitzdGF0aWMgaW50CitraWxs
X3Byb2Nlc3NfdHJlZSAoaW50IHBpZCwgaW50IHNpZykKK3sKKyAgUFJPQ0VTU0VOVFJZMzIgcHJv
Y2Vzc19lbnRyeTsKKyAgSEFORExFIHNuYXBzaG90OworCisgIHByb2Nlc3NfZW50cnkuZHdTaXpl
ID0gc2l6ZW9mIChwcm9jZXNzX2VudHJ5KTsKKyAgc25hcHNob3QgPSBDcmVhdGVUb29saGVscDMy
U25hcHNob3QgKFRIMzJDU19TTkFQUFJPQ0VTUywgcGlkKTsKKworICBraWxsX3Byb2Nlc3MgKHBp
ZCwgc2lnKTsKKyAgUHJvY2VzczMyRmlyc3QgKHNuYXBzaG90LCAmcHJvY2Vzc19lbnRyeSk7Cisg
IGRvCisgICAgeworICAgICAgaWYgKHByb2Nlc3NfZW50cnkudGgzMlBhcmVudFByb2Nlc3NJRCA9
PSBwaWQpCisgICAgICAgIGtpbGxfcHJvY2Vzc190cmVlIChwcm9jZXNzX2VudHJ5LnRoMzJQcm9j
ZXNzSUQsIHNpZyk7CisgICAgfSB3aGlsZSAoUHJvY2VzczMyTmV4dCAoc25hcHNob3QsICZwcm9j
ZXNzX2VudHJ5KSk7CisgIENsb3NlSGFuZGxlIChzbmFwc2hvdCk7CisgIHJldHVybiAwOworfQor
CisvKiBFbXVsYXRlICdraWxsJywgYnV0IG9ubHkgZm9yIG90aGVyIHByb2Nlc3Nlcy4gICovCitp
bnQKK3N5c19raWxsIChpbnQgcGlkLCBpbnQgc2lnKQoreworICBpZiAocGlkIDwgMCkKKyAgICBy
ZXR1cm4ga2lsbF9wcm9jZXNzX3RyZWUgKC1waWQsIHNpZyk7CisgIGVsc2UKKyAgICByZXR1cm4g
a2lsbF9wcm9jZXNzIChwaWQsIHNpZyk7Cit9CisKIC8qIFRoZSBmb2xsb3dpbmcgdHdvIHJvdXRp
bmVzIGFyZSB1c2VkIHRvIG1hbmlwdWxhdGUgc3RkaW4sIHN0ZG91dCwgYW5kCiAgICBzdGRlcnIg
b2Ygb3VyIGNoaWxkIHByb2Nlc3Nlcy4KIAo=
--047d7bb0437408573c04ede50a5c--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#15983: 24.3; Emacs Not Killing Child Process
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 19 Dec 2013 17:25:01 +0000
Resent-Message-ID: <handler.15983.B.138747388317910 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 15983
X-GNU-PR-Package: emacs,w32
X-GNU-PR-Keywords: 
To: Joan Karadimov <joan.karadimov@HIDDEN>
Cc: bozhidar.batsov@HIDDEN, 15983 <at> debbugs.gnu.org, sjm@HIDDEN
X-Debbugs-Original-Cc: bozhidar.batsov@HIDDEN, bug-gnu-emacs@HIDDEN, sjm@HIDDEN
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Received: via spool by submit <at> debbugs.gnu.org id=B.138747388317910
          (code B ref -1); Thu, 19 Dec 2013 17:25:01 +0000
Received: (at submit) by debbugs.gnu.org; 19 Dec 2013 17:24:43 +0000
Received: from localhost ([127.0.0.1]:58864 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1VthL0-0004em-8s
	for submit <at> debbugs.gnu.org; Thu, 19 Dec 2013 12:24:42 -0500
Received: from eggs.gnu.org ([208.118.235.92]:53626)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <eliz@HIDDEN>) id 1VthKx-0004ec-5v
 for submit <at> debbugs.gnu.org; Thu, 19 Dec 2013 12:24:39 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1VthKr-0002e9-90
 for submit <at> debbugs.gnu.org; Thu, 19 Dec 2013 12:24:38 -0500
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD
 autolearn=disabled version=3.3.2
Received: from lists.gnu.org ([2001:4830:134:3::11]:50088)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1VthKr-0002e5-5f
 for submit <at> debbugs.gnu.org; Thu, 19 Dec 2013 12:24:33 -0500
Received: from eggs.gnu.org ([2001:4830:134:3::10]:55338)
 by lists.gnu.org with esmtp (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1VthKl-0003sq-Ng
 for bug-gnu-emacs@HIDDEN; Thu, 19 Dec 2013 12:24:33 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1VthKg-0002ca-G8
 for bug-gnu-emacs@HIDDEN; Thu, 19 Dec 2013 12:24:27 -0500
Received: from mtaout20.012.net.il ([80.179.55.166]:52379)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1VthKg-0002cW-7a
 for bug-gnu-emacs@HIDDEN; Thu, 19 Dec 2013 12:24:22 -0500
Received: from conversion-daemon.a-mtaout20.012.net.il by
 a-mtaout20.012.net.il (HyperSendmail v2007.08) id
 <0MY200C00D3GP000@HIDDEN> for bug-gnu-emacs@HIDDEN;
 Thu, 19 Dec 2013 19:24:16 +0200 (IST)
Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il
 (HyperSendmail v2007.08) with ESMTPA id
 <0MY200B6MDOFC5V0@HIDDEN>;
 Thu, 19 Dec 2013 19:24:16 +0200 (IST)
Date: Thu, 19 Dec 2013 19:24:34 +0200
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <CAGVACNVfa8bvqHDOavzUzb6mGCxRHPzu2Pbv4Yi-76Ca+B_Rcw@HIDDEN>
X-012-Sender: halo1@HIDDEN
Message-id: <83ob4cbvot.fsf@HIDDEN>
References: <CAGVACNVfa8bvqHDOavzUzb6mGCxRHPzu2Pbv4Yi-76Ca+B_Rcw@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: Solaris 10
X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address
 (bad octet value).
X-Received-From: 2001:4830:134:3::11
X-Spam-Score: -5.5 (-----)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.5 (-----)

> Date: Thu, 19 Dec 2013 17:44:37 +0200
> From: Joan Karadimov <joan.karadimov@HIDDEN>
> Cc: sjm@HIDDEN, eliz@HIDDEN, Bozhidar Batsov <bozhidar.batsov@HIDDEN>
> 
> > Emacs on Windows can only monitor and kill its immediate subprocesses,
> > it cannot monitor, let alone kill, any of their descendant processes,> because it has no idea about them.  And the OS doesn't automatically> kill all the processes in the subprocess tree, and there's no way to> send a signal to them all, as on Posix platforms.  If killing the> immediate child process doesn't cause some of its children to exit or> abort, then those grandchildren will be left orphaned.
> Windows NT does have the concept of parent processes, but an API call
> wasn't exposed in win32 until XP. I wrote a small patch that uses that
> and kills all child processes (as long as pid<0). I did some sanity
> testing and it works.

Thanks, but I don't think we can use this code safely: there's a race
condition here between the time the snapshot is taken and the time the
process in the snapshot is killed.  During this time window, however
small, a process ID can be reused for a completely different process.
Killing an unrelated process is a no-no.

Moreover, AFAIU the code takes multiple independent snapshots of the
process tree, which are not guaranteed to be consistent between them
on a live system which resuses process IDs as fast as Windows does.

The only safe way on Windows to make sure a process ID is not reused
is to keep a handle open on the process.  But such a strategy would
require some kind of notification to Emacs from its subprocesses when
they launch their subprocesses.  If you (or someone else) know how to
set this up, we could indeed resolve this problem.  Otherwise, I'm
afraid we will need to live with this some more.

> - there is no OS detection - this will get ugly on Windows 9x and
> NT4/5.0

This is not a problem: we already call these functions in Emacs, and
have the necessary machinery to detect whether the API is available.
Take a look at create_toolhelp32_snapshot in w32.c, and its callers.

> - performance: 3 API calls are made for each descendant
> process. This can be reduced to a total 3 calls (regardless of the
> child process count)

I doubt that this should count as a problem, since we are talking
about extreme cases anyway.

The only real problem is the one I mention above.

Thanks for working on this.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#15983: 24.3; Emacs Not Killing Child Process
Resent-From: Joan Karadimov <joan.karadimov@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 20 Dec 2013 22:29:02 +0000
Resent-Message-ID: <handler.15983.B.13875784928701 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 15983
X-GNU-PR-Package: emacs,w32
X-GNU-PR-Keywords: 
To: 15983 <at> debbugs.gnu.org, eliz@HIDDEN
Cc: Bozhidar Batsov <bozhidar.batsov@HIDDEN>, Simon Morgan <sjm@HIDDEN>
X-Debbugs-Original-To: bug-gnu-emacs@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, 15983 <at> debbugs.gnu.org
Received: via spool by submit <at> debbugs.gnu.org id=B.13875784928701
          (code B ref -1); Fri, 20 Dec 2013 22:29:02 +0000
Received: (at submit) by debbugs.gnu.org; 20 Dec 2013 22:28:12 +0000
Received: from localhost ([127.0.0.1]:60534 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1Vu8YG-0002GG-0M
	for submit <at> debbugs.gnu.org; Fri, 20 Dec 2013 17:28:12 -0500
Received: from eggs.gnu.org ([208.118.235.92]:59876)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <joan.karadimov@HIDDEN>) id 1Vu8YD-0002G7-G7
 for submit <at> debbugs.gnu.org; Fri, 20 Dec 2013 17:28:10 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <joan.karadimov@HIDDEN>) id 1Vu8YB-0007YY-IP
 for submit <at> debbugs.gnu.org; Fri, 20 Dec 2013 17:28:09 -0500
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: *
X-Spam-Status: No, score=1.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM,
 FREEMAIL_REPLY,HTML_MESSAGE,T_DKIM_INVALID autolearn=disabled version=3.3.2
Received: from lists.gnu.org ([2001:4830:134:3::11]:50470)
 by eggs.gnu.org with esmtp (Exim 4.71)
 (envelope-from <joan.karadimov@HIDDEN>) id 1Vu8YB-0007YU-Ev
 for submit <at> debbugs.gnu.org; Fri, 20 Dec 2013 17:28:07 -0500
Received: from eggs.gnu.org ([2001:4830:134:3::10]:33358)
 by lists.gnu.org with esmtp (Exim 4.71)
 (envelope-from <joan.karadimov@HIDDEN>) id 1Vu8YA-0004H2-3j
 for bug-gnu-emacs@HIDDEN; Fri, 20 Dec 2013 17:28:07 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <joan.karadimov@HIDDEN>) id 1Vu8Y8-0007YF-OX
 for bug-gnu-emacs@HIDDEN; Fri, 20 Dec 2013 17:28:06 -0500
Received: from mail-we0-x22b.google.com ([2a00:1450:400c:c03::22b]:39212)
 by eggs.gnu.org with esmtp (Exim 4.71)
 (envelope-from <joan.karadimov@HIDDEN>)
 id 1Vu8Y8-0007Y7-B1; Fri, 20 Dec 2013 17:28:04 -0500
Received: by mail-we0-f171.google.com with SMTP id q58so3101689wes.16
 for <multiple recipients>; Fri, 20 Dec 2013 14:28:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=mime-version:in-reply-to:references:date:message-id:subject:from:to
 :cc:content-type;
 bh=+AzkFf6geIL2C7FayD6Wq1c2gJPzIVOSJBKshwiXFHs=;
 b=WdOROICPBDO+AVFnKxpWeGGCfbwtuugp/P7oOijur8NGWQMZpByMQq1FiKLX37p5vH
 vDqdFpt7DI2Vol8FUGS5E9IEWgtQpuVCVsLjelhgQsKBokAJdg2AAOyBoqmeGxNs7OYR
 BFwg/w9K5bx+CO84+VvkgJ7yggmgDsdee2DYpHUGpntx58//9HoKtPPT4XIIud7zb29n
 JphtI3k6j/hDhhFLIkTXToe9phnGIPLDeGqP91BazDtIB5kNZGIX8r4ncklnGr+tKj2p
 MQHeUGc5mx9aYWLQzvrFGlJZIJoypDDNnratiuhVjVMNwRBQf1xyXUwNbV3EzhKOyjkV
 Bp8w==
MIME-Version: 1.0
X-Received: by 10.180.24.99 with SMTP id t3mr9938666wif.1.1387578482711; Fri,
 20 Dec 2013 14:28:02 -0800 (PST)
Received: by 10.216.127.68 with HTTP; Fri, 20 Dec 2013 14:28:02 -0800 (PST)
In-Reply-To: <83ob4cbvot.fsf@HIDDEN>
References: <CAGVACNVfa8bvqHDOavzUzb6mGCxRHPzu2Pbv4Yi-76Ca+B_Rcw@HIDDEN>
 <83ob4cbvot.fsf@HIDDEN>
Date: Sat, 21 Dec 2013 00:28:02 +0200
Message-ID: <CAGVACNVaXbjPkm4YU3p+HhNxehJ-eBm1daPXuaBCRXfqM8zMTA@HIDDEN>
From: Joan Karadimov <joan.karadimov@HIDDEN>
Content-Type: multipart/alternative; boundary=f46d043c80cc8f63c904edfecad4
X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address
 (bad octet value).
X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address
 (bad octet value).
X-Received-From: 2001:4830:134:3::11
X-Spam-Score: -3.0 (---)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -4.0 (----)

--f46d043c80cc8f63c904edfecad4
Content-Type: text/plain; charset=ISO-8859-1

Thanks for the feedback!

Taking multiple independent snapshots is not something I intended to leave
this way.This is what I was referring to in the "performace" part of the
issues.

Back to the main issue - I wasn't aware that pid's get reused so rapidly on
Windows.

As for the implementation - your idea sounds great but I have no idea how to
put it together.

I am able to come up with some other stuff that use snapshots and do not
kill
unrelated processes. However, they skip any processes that are spawned after
the sys_kill subroutine is called.

Now I am starting to think in another direction. Would something like:
  system("taskkill /PID XXXX /T")
... be an acceptable solution?

On Thu, Dec 19, 2013 at 7:24 PM, Eli Zaretskii <eliz@HIDDEN> wrote:

> > Date: Thu, 19 Dec 2013 17:44:37 +0200
> > From: Joan Karadimov <joan.karadimov@HIDDEN>
> > Cc: sjm@HIDDEN, eliz@HIDDEN, Bozhidar Batsov <bozhidar.batsov@HIDDEN
> >
> >
> > > Emacs on Windows can only monitor and kill its immediate subprocesses,
> > > it cannot monitor, let alone kill, any of their descendant processes,>
> because it has no idea about them.  And the OS doesn't automatically> kill
> all the processes in the subprocess tree, and there's no way to> send a
> signal to them all, as on Posix platforms.  If killing the> immediate child
> process doesn't cause some of its children to exit or> abort, then those
> grandchildren will be left orphaned.
> > Windows NT does have the concept of parent processes, but an API call
> > wasn't exposed in win32 until XP. I wrote a small patch that uses that
> > and kills all child processes (as long as pid<0). I did some sanity
> > testing and it works.
>
> Thanks, but I don't think we can use this code safely: there's a race
> condition here between the time the snapshot is taken and the time the
> process in the snapshot is killed.  During this time window, however
> small, a process ID can be reused for a completely different process.
> Killing an unrelated process is a no-no.
>
> Moreover, AFAIU the code takes multiple independent snapshots of the
> process tree, which are not guaranteed to be consistent between them
> on a live system which resuses process IDs as fast as Windows does.
>
> The only safe way on Windows to make sure a process ID is not reused
> is to keep a handle open on the process.  But such a strategy would
> require some kind of notification to Emacs from its subprocesses when
> they launch their subprocesses.  If you (or someone else) know how to
> set this up, we could indeed resolve this problem.  Otherwise, I'm
> afraid we will need to live with this some more.
>
> > - there is no OS detection - this will get ugly on Windows 9x and
> > NT4/5.0
>
> This is not a problem: we already call these functions in Emacs, and
> have the necessary machinery to detect whether the API is available.
> Take a look at create_toolhelp32_snapshot in w32.c, and its callers.
>
> > - performance: 3 API calls are made for each descendant
> > process. This can be reduced to a total 3 calls (regardless of the
> > child process count)
>
> I doubt that this should count as a problem, since we are talking
> about extreme cases anyway.
>
> The only real problem is the one I mention above.
>
> Thanks for working on this.
>

--f46d043c80cc8f63c904edfecad4
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Thanks for the feedback!<br></div><div><br></div><div=
>Taking multiple independent snapshots is not something I intended to leave=
</div><div>this way.This is what I was referring to in the &quot;performace=
&quot; part of the</div>

<div>issues.</div><div><br></div><div>Back to the main issue - I wasn&#39;t=
 aware that pid&#39;s get reused so rapidly on</div><div>Windows.</div><div=
><br></div><div>As for the implementation - your idea sounds great but I ha=
ve no idea how to</div>
<div>put it together.</div><div><br></div><div>I am able to come up with so=
me other stuff that use snapshots and do not kill</div><div>unrelated proce=
sses. However, they skip any processes that are spawned after</div><div>
the sys_kill subroutine is called.</div><div><br></div><div>Now I am starti=
ng to think in another direction. Would something like:</div><div>=A0 syste=
m(&quot;taskkill /PID XXXX /T&quot;)</div><div>... be an acceptable solutio=
n?</div>
<div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Thu, Dec =
19, 2013 at 7:24 PM, Eli Zaretskii <span dir=3D"ltr">&lt;<a href=3D"mailto:=
eliz@HIDDEN" target=3D"_blank">eliz@HIDDEN</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">&gt; Date: Thu, 19 Dec 2013 17:44:37 +0200<br>
&gt; From: Joan Karadimov &lt;<a href=3D"mailto:joan.karadimov@HIDDEN" t=
arget=3D"_blank">joan.karadimov@HIDDEN</a>&gt;<br>
&gt; Cc: <a href=3D"mailto:sjm@HIDDEN" target=3D"_blank">sjm@HIDDEN</a>, <a=
 href=3D"mailto:eliz@HIDDEN" target=3D"_blank">eliz@HIDDEN</a>, Bozhidar =
Batsov &lt;<a href=3D"mailto:bozhidar.batsov@HIDDEN" target=3D"_blank">b=
ozhidar.batsov@HIDDEN</a>&gt;<br>

<div>&gt;<br>
&gt; &gt; Emacs on Windows can only monitor and kill its immediate subproce=
sses,<br>
&gt; &gt; it cannot monitor, let alone kill, any of their descendant proces=
ses,&gt; because it has no idea about them. =A0And the OS doesn&#39;t autom=
atically&gt; kill all the processes in the subprocess tree, and there&#39;s=
 no way to&gt; send a signal to them all, as on Posix platforms. =A0If kill=
ing the&gt; immediate child process doesn&#39;t cause some of its children =
to exit or&gt; abort, then those grandchildren will be left orphaned.<br>


&gt; Windows NT does have the concept of parent processes, but an API call<=
br>
&gt; wasn&#39;t exposed in win32 until XP. I wrote a small patch that uses =
that<br>
&gt; and kills all child processes (as long as pid&lt;0). I did some sanity=
<br>
&gt; testing and it works.<br>
<br>
</div>Thanks, but I don&#39;t think we can use this code safely: there&#39;=
s a race<br>
condition here between the time the snapshot is taken and the time the<br>
process in the snapshot is killed. =A0During this time window, however<br>
small, a process ID can be reused for a completely different process.<br>
Killing an unrelated process is a no-no.<br>
<br>
Moreover, AFAIU the code takes multiple independent snapshots of the<br>
process tree, which are not guaranteed to be consistent between them<br>
on a live system which resuses process IDs as fast as Windows does.<br>
<br>
The only safe way on Windows to make sure a process ID is not reused<br>
is to keep a handle open on the process. =A0But such a strategy would<br>
require some kind of notification to Emacs from its subprocesses when<br>
they launch their subprocesses. =A0If you (or someone else) know how to<br>
set this up, we could indeed resolve this problem. =A0Otherwise, I&#39;m<br=
>
afraid we will need to live with this some more.<br>
<div><br>
&gt; - there is no OS detection - this will get ugly on Windows 9x and<br>
&gt; NT4/5.0<br>
<br>
</div>This is not a problem: we already call these functions in Emacs, and<=
br>
have the necessary machinery to detect whether the API is available.<br>
Take a look at create_toolhelp32_snapshot in w32.c, and its callers.<br>
<div><br>
&gt; - performance: 3 API calls are made for each descendant<br>
&gt; process. This can be reduced to a total 3 calls (regardless of the<br>
&gt; child process count)<br>
<br>
</div>I doubt that this should count as a problem, since we are talking<br>
about extreme cases anyway.<br>
<br>
The only real problem is the one I mention above.<br>
<br>
Thanks for working on this.<br>
</blockquote></div><br></div></div></div>

--f46d043c80cc8f63c904edfecad4--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#15983: 24.3; Emacs Not Killing Child Process
Resent-From: Joan Karadimov <joan.karadimov@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 20 Dec 2013 22:29:02 +0000
Resent-Message-ID: <handler.15983.B15983.13875784888683 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 15983
X-GNU-PR-Package: emacs,w32
X-GNU-PR-Keywords: 
To: 15983 <at> debbugs.gnu.org, eliz@HIDDEN
Cc: Bozhidar Batsov <bozhidar.batsov@HIDDEN>, Simon Morgan <sjm@HIDDEN>
X-Debbugs-Original-To: bug-gnu-emacs@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, 15983 <at> debbugs.gnu.org
Received: via spool by 15983-submit <at> debbugs.gnu.org id=B15983.13875784888683
          (code B ref 15983); Fri, 20 Dec 2013 22:29:02 +0000
Received: (at 15983) by debbugs.gnu.org; 20 Dec 2013 22:28:08 +0000
Received: from localhost ([127.0.0.1]:60531 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1Vu8YB-0002Fz-8N
	for submit <at> debbugs.gnu.org; Fri, 20 Dec 2013 17:28:07 -0500
Received: from mail-we0-f170.google.com ([74.125.82.170]:57468)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <joan.karadimov@HIDDEN>) id 1Vu8Y7-0002Fm-Ix
 for 15983 <at> debbugs.gnu.org; Fri, 20 Dec 2013 17:28:04 -0500
Received: by mail-we0-f170.google.com with SMTP id w61so3108369wes.1
 for <15983 <at> debbugs.gnu.org>; Fri, 20 Dec 2013 14:28:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=mime-version:in-reply-to:references:date:message-id:subject:from:to
 :cc:content-type;
 bh=+AzkFf6geIL2C7FayD6Wq1c2gJPzIVOSJBKshwiXFHs=;
 b=WdOROICPBDO+AVFnKxpWeGGCfbwtuugp/P7oOijur8NGWQMZpByMQq1FiKLX37p5vH
 vDqdFpt7DI2Vol8FUGS5E9IEWgtQpuVCVsLjelhgQsKBokAJdg2AAOyBoqmeGxNs7OYR
 BFwg/w9K5bx+CO84+VvkgJ7yggmgDsdee2DYpHUGpntx58//9HoKtPPT4XIIud7zb29n
 JphtI3k6j/hDhhFLIkTXToe9phnGIPLDeGqP91BazDtIB5kNZGIX8r4ncklnGr+tKj2p
 MQHeUGc5mx9aYWLQzvrFGlJZIJoypDDNnratiuhVjVMNwRBQf1xyXUwNbV3EzhKOyjkV
 Bp8w==
MIME-Version: 1.0
X-Received: by 10.180.24.99 with SMTP id t3mr9938666wif.1.1387578482711; Fri,
 20 Dec 2013 14:28:02 -0800 (PST)
Received: by 10.216.127.68 with HTTP; Fri, 20 Dec 2013 14:28:02 -0800 (PST)
In-Reply-To: <83ob4cbvot.fsf@HIDDEN>
References: <CAGVACNVfa8bvqHDOavzUzb6mGCxRHPzu2Pbv4Yi-76Ca+B_Rcw@HIDDEN>
 <83ob4cbvot.fsf@HIDDEN>
Date: Sat, 21 Dec 2013 00:28:02 +0200
Message-ID: <CAGVACNVaXbjPkm4YU3p+HhNxehJ-eBm1daPXuaBCRXfqM8zMTA@HIDDEN>
From: Joan Karadimov <joan.karadimov@HIDDEN>
Content-Type: multipart/alternative; boundary=f46d043c80cc8f63c904edfecad4
X-Spam-Score: 0.3 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

--f46d043c80cc8f63c904edfecad4
Content-Type: text/plain; charset=ISO-8859-1

Thanks for the feedback!

Taking multiple independent snapshots is not something I intended to leave
this way.This is what I was referring to in the "performace" part of the
issues.

Back to the main issue - I wasn't aware that pid's get reused so rapidly on
Windows.

As for the implementation - your idea sounds great but I have no idea how to
put it together.

I am able to come up with some other stuff that use snapshots and do not
kill
unrelated processes. However, they skip any processes that are spawned after
the sys_kill subroutine is called.

Now I am starting to think in another direction. Would something like:
  system("taskkill /PID XXXX /T")
... be an acceptable solution?

On Thu, Dec 19, 2013 at 7:24 PM, Eli Zaretskii <eliz@HIDDEN> wrote:

> > Date: Thu, 19 Dec 2013 17:44:37 +0200
> > From: Joan Karadimov <joan.karadimov@HIDDEN>
> > Cc: sjm@HIDDEN, eliz@HIDDEN, Bozhidar Batsov <bozhidar.batsov@HIDDEN
> >
> >
> > > Emacs on Windows can only monitor and kill its immediate subprocesses,
> > > it cannot monitor, let alone kill, any of their descendant processes,>
> because it has no idea about them.  And the OS doesn't automatically> kill
> all the processes in the subprocess tree, and there's no way to> send a
> signal to them all, as on Posix platforms.  If killing the> immediate child
> process doesn't cause some of its children to exit or> abort, then those
> grandchildren will be left orphaned.
> > Windows NT does have the concept of parent processes, but an API call
> > wasn't exposed in win32 until XP. I wrote a small patch that uses that
> > and kills all child processes (as long as pid<0). I did some sanity
> > testing and it works.
>
> Thanks, but I don't think we can use this code safely: there's a race
> condition here between the time the snapshot is taken and the time the
> process in the snapshot is killed.  During this time window, however
> small, a process ID can be reused for a completely different process.
> Killing an unrelated process is a no-no.
>
> Moreover, AFAIU the code takes multiple independent snapshots of the
> process tree, which are not guaranteed to be consistent between them
> on a live system which resuses process IDs as fast as Windows does.
>
> The only safe way on Windows to make sure a process ID is not reused
> is to keep a handle open on the process.  But such a strategy would
> require some kind of notification to Emacs from its subprocesses when
> they launch their subprocesses.  If you (or someone else) know how to
> set this up, we could indeed resolve this problem.  Otherwise, I'm
> afraid we will need to live with this some more.
>
> > - there is no OS detection - this will get ugly on Windows 9x and
> > NT4/5.0
>
> This is not a problem: we already call these functions in Emacs, and
> have the necessary machinery to detect whether the API is available.
> Take a look at create_toolhelp32_snapshot in w32.c, and its callers.
>
> > - performance: 3 API calls are made for each descendant
> > process. This can be reduced to a total 3 calls (regardless of the
> > child process count)
>
> I doubt that this should count as a problem, since we are talking
> about extreme cases anyway.
>
> The only real problem is the one I mention above.
>
> Thanks for working on this.
>

--f46d043c80cc8f63c904edfecad4
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Thanks for the feedback!<br></div><div><br></div><div=
>Taking multiple independent snapshots is not something I intended to leave=
</div><div>this way.This is what I was referring to in the &quot;performace=
&quot; part of the</div>

<div>issues.</div><div><br></div><div>Back to the main issue - I wasn&#39;t=
 aware that pid&#39;s get reused so rapidly on</div><div>Windows.</div><div=
><br></div><div>As for the implementation - your idea sounds great but I ha=
ve no idea how to</div>
<div>put it together.</div><div><br></div><div>I am able to come up with so=
me other stuff that use snapshots and do not kill</div><div>unrelated proce=
sses. However, they skip any processes that are spawned after</div><div>
the sys_kill subroutine is called.</div><div><br></div><div>Now I am starti=
ng to think in another direction. Would something like:</div><div>=A0 syste=
m(&quot;taskkill /PID XXXX /T&quot;)</div><div>... be an acceptable solutio=
n?</div>
<div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Thu, Dec =
19, 2013 at 7:24 PM, Eli Zaretskii <span dir=3D"ltr">&lt;<a href=3D"mailto:=
eliz@HIDDEN" target=3D"_blank">eliz@HIDDEN</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">&gt; Date: Thu, 19 Dec 2013 17:44:37 +0200<br>
&gt; From: Joan Karadimov &lt;<a href=3D"mailto:joan.karadimov@HIDDEN" t=
arget=3D"_blank">joan.karadimov@HIDDEN</a>&gt;<br>
&gt; Cc: <a href=3D"mailto:sjm@HIDDEN" target=3D"_blank">sjm@HIDDEN</a>, <a=
 href=3D"mailto:eliz@HIDDEN" target=3D"_blank">eliz@HIDDEN</a>, Bozhidar =
Batsov &lt;<a href=3D"mailto:bozhidar.batsov@HIDDEN" target=3D"_blank">b=
ozhidar.batsov@HIDDEN</a>&gt;<br>

<div>&gt;<br>
&gt; &gt; Emacs on Windows can only monitor and kill its immediate subproce=
sses,<br>
&gt; &gt; it cannot monitor, let alone kill, any of their descendant proces=
ses,&gt; because it has no idea about them. =A0And the OS doesn&#39;t autom=
atically&gt; kill all the processes in the subprocess tree, and there&#39;s=
 no way to&gt; send a signal to them all, as on Posix platforms. =A0If kill=
ing the&gt; immediate child process doesn&#39;t cause some of its children =
to exit or&gt; abort, then those grandchildren will be left orphaned.<br>


&gt; Windows NT does have the concept of parent processes, but an API call<=
br>
&gt; wasn&#39;t exposed in win32 until XP. I wrote a small patch that uses =
that<br>
&gt; and kills all child processes (as long as pid&lt;0). I did some sanity=
<br>
&gt; testing and it works.<br>
<br>
</div>Thanks, but I don&#39;t think we can use this code safely: there&#39;=
s a race<br>
condition here between the time the snapshot is taken and the time the<br>
process in the snapshot is killed. =A0During this time window, however<br>
small, a process ID can be reused for a completely different process.<br>
Killing an unrelated process is a no-no.<br>
<br>
Moreover, AFAIU the code takes multiple independent snapshots of the<br>
process tree, which are not guaranteed to be consistent between them<br>
on a live system which resuses process IDs as fast as Windows does.<br>
<br>
The only safe way on Windows to make sure a process ID is not reused<br>
is to keep a handle open on the process. =A0But such a strategy would<br>
require some kind of notification to Emacs from its subprocesses when<br>
they launch their subprocesses. =A0If you (or someone else) know how to<br>
set this up, we could indeed resolve this problem. =A0Otherwise, I&#39;m<br=
>
afraid we will need to live with this some more.<br>
<div><br>
&gt; - there is no OS detection - this will get ugly on Windows 9x and<br>
&gt; NT4/5.0<br>
<br>
</div>This is not a problem: we already call these functions in Emacs, and<=
br>
have the necessary machinery to detect whether the API is available.<br>
Take a look at create_toolhelp32_snapshot in w32.c, and its callers.<br>
<div><br>
&gt; - performance: 3 API calls are made for each descendant<br>
&gt; process. This can be reduced to a total 3 calls (regardless of the<br>
&gt; child process count)<br>
<br>
</div>I doubt that this should count as a problem, since we are talking<br>
about extreme cases anyway.<br>
<br>
The only real problem is the one I mention above.<br>
<br>
Thanks for working on this.<br>
</blockquote></div><br></div></div></div>

--f46d043c80cc8f63c904edfecad4--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#15983: 24.3; Emacs Not Killing Child Process
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 21 Dec 2013 08:16:02 +0000
Resent-Message-ID: <handler.15983.B15983.138761374716052 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 15983
X-GNU-PR-Package: emacs,w32
X-GNU-PR-Keywords: 
To: Joan Karadimov <joan.karadimov@HIDDEN>
Cc: bozhidar.batsov@HIDDEN, sjm@HIDDEN, 15983 <at> debbugs.gnu.org
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 15983-submit <at> debbugs.gnu.org id=B15983.138761374716052
          (code B ref 15983); Sat, 21 Dec 2013 08:16:02 +0000
Received: (at 15983) by debbugs.gnu.org; 21 Dec 2013 08:15:47 +0000
Received: from localhost ([127.0.0.1]:60758 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1VuHis-0004Aq-Lu
	for submit <at> debbugs.gnu.org; Sat, 21 Dec 2013 03:15:46 -0500
Received: from mtaout20.012.net.il ([80.179.55.166]:63035)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <eliz@HIDDEN>) id 1VuHio-0004Ab-6l
 for 15983 <at> debbugs.gnu.org; Sat, 21 Dec 2013 03:15:43 -0500
Received: from conversion-daemon.a-mtaout20.012.net.il by
 a-mtaout20.012.net.il (HyperSendmail v2007.08) id
 <0MY500500DEJ9Z00@HIDDEN> for 15983 <at> debbugs.gnu.org;
 Sat, 21 Dec 2013 10:15:21 +0200 (IST)
Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il
 (HyperSendmail v2007.08) with ESMTPA id
 <0MY5005MLDLK8I40@HIDDEN>;
 Sat, 21 Dec 2013 10:15:21 +0200 (IST)
Date: Sat, 21 Dec 2013 10:15:07 +0200
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <CAGVACNVaXbjPkm4YU3p+HhNxehJ-eBm1daPXuaBCRXfqM8zMTA@HIDDEN>
X-012-Sender: halo1@HIDDEN
Message-id: <83txe2aad0.fsf@HIDDEN>
References: <CAGVACNVfa8bvqHDOavzUzb6mGCxRHPzu2Pbv4Yi-76Ca+B_Rcw@HIDDEN>
 <83ob4cbvot.fsf@HIDDEN>
 <CAGVACNVaXbjPkm4YU3p+HhNxehJ-eBm1daPXuaBCRXfqM8zMTA@HIDDEN>
X-Spam-Score: 2.2 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has
 identified this incoming email as possible spam.  The original message
 has been attached to this so you can view it (if it isn't spam) or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview:  > Date: Sat,
 21 Dec 2013 00:28:02 +0200 > From: Joan Karadimov
 <joan.karadimov@HIDDEN> > Cc: Simon Morgan <sjm@HIDDEN>, Bozhidar Batsov
 <bozhidar.batsov@HIDDEN> > > Back to the main issue - I wasn't aware that
 pid's get reused so rapidly on > Windows. [...] 
 Content analysis details:   (2.2 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 1.2 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net
 [Blocked - see <http://www.spamcop.net/bl.shtml?80.179.55.166>]
 -0.0 RCVD_IN_DNSWL_NONE     RBL: Sender listed at http://www.dnswl.org/, no
 trust [80.179.55.166 listed in list.dnswl.org]
 1.0 SPF_SOFTFAIL           SPF: sender does not match SPF record (softfail)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 2.2 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has
 identified this incoming email as possible spam.  The original message
 has been attached to this so you can view it (if it isn't spam) or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 
 Content preview:  > Date: Sat, 21 Dec 2013 00:28:02 +0200 > From: Joan Karadimov
    <joan.karadimov@HIDDEN> > Cc: Simon Morgan <sjm@HIDDEN>, Bozhidar Batsov
    <bozhidar.batsov@HIDDEN> > > Back to the main issue - I wasn't aware that
    pid's get reused so rapidly on > Windows. [...] 
 
 Content analysis details:   (2.2 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.0 RCVD_IN_DNSWL_NONE     RBL: Sender listed at http://www.dnswl.org/, no
                             trust
                             [80.179.55.166 listed in list.dnswl.org]
  1.2 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net
                [Blocked - see <http://www.spamcop.net/bl.shtml?80.179.55.166>]
  1.0 SPF_SOFTFAIL           SPF: sender does not match SPF record (softfail)

> Date: Sat, 21 Dec 2013 00:28:02 +0200
> From: Joan Karadimov <joan.karadimov@HIDDEN>
> Cc: Simon Morgan <sjm@HIDDEN>, Bozhidar Batsov <bozhidar.batsov@HIDDEN>
> 
> Back to the main issue - I wasn't aware that pid's get reused so rapidly on
> Windows.

Windows uses the same pool of numbers for process and thread IDs, so
the numbers are reused very quickly.

> As for the implementation - your idea sounds great but I have no idea how to
> put it together.

Neither do I.

> I am able to come up with some other stuff that use snapshots and do not
> kill
> unrelated processes. However, they skip any processes that are spawned after
> the sys_kill subroutine is called.

This might be "good enough" -- we err on the safe side, and only leave
some subprocesses not killed in rare situations.  Does this strategy
solve the problem which started this bug report?  If so, please tell
the main ideas of how you intend to avoid killing unrelated processes.

> Now I am starting to think in another direction. Would something like:
>   system("taskkill /PID XXXX /T")
> ... be an acceptable solution?

Unfortunately, taskkill is not available widely enough.  E.g., on my
XP Home edition, it is not available, and I believe it is not there on
systems older than XP, which we still support.

Thanks.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#15983: 24.3; Emacs Not Killing Child Process
Resent-From: Joan Karadimov <joan.karadimov@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 21 Dec 2013 16:23:02 +0000
Resent-Message-ID: <handler.15983.B15983.138764293113587 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 15983
X-GNU-PR-Package: emacs,w32
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: Bozhidar Batsov <bozhidar.batsov@HIDDEN>, Simon Morgan <sjm@HIDDEN>, 15983 <at> debbugs.gnu.org
Received: via spool by 15983-submit <at> debbugs.gnu.org id=B15983.138764293113587
          (code B ref 15983); Sat, 21 Dec 2013 16:23:02 +0000
Received: (at 15983) by debbugs.gnu.org; 21 Dec 2013 16:22:11 +0000
Received: from localhost ([127.0.0.1]:33403 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1VuPJa-0003X3-1Q
	for submit <at> debbugs.gnu.org; Sat, 21 Dec 2013 11:22:10 -0500
Received: from mail-wg0-f48.google.com ([74.125.82.48]:51176)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <joan.karadimov@HIDDEN>) id 1VuPJX-0003Wp-F0
 for 15983 <at> debbugs.gnu.org; Sat, 21 Dec 2013 11:22:08 -0500
Received: by mail-wg0-f48.google.com with SMTP id z12so3544831wgg.3
 for <15983 <at> debbugs.gnu.org>; Sat, 21 Dec 2013 08:22:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=mime-version:in-reply-to:references:date:message-id:subject:from:to
 :cc:content-type;
 bh=k8rLqnmEQMxaowiaL/eFmfasR7o4JAGTDfgx0NOeqN4=;
 b=g/aYl2YOa2dsJCBdiKTIRAIm3Fi7bcthK5SE7NY8L+K8SRonf/4gBqxekDH/tqln2w
 b+GjtqwGDgqXe+jl4+2cJpFkLeWd59EmTIvaqquH/8QItX6SlQkQVHCC7IsNZ9pFdKKA
 OLGqr9oVQqYVsRhw+ybLXNwuHETBYry+EPjdSI9OjXUjfC3ntHurFTGG+RYjrimAnZFK
 CJo53VLHrodC5zkhIkeWqASjcUrJTMj81GkVwUWvDcPTLohMeKtdgG43maqUuLWWW390
 oLQ8RFCR006kuf10b1+Id4dT54vv2vqvVEN3YLzUgT2cXK+SMlIobd3dofOjcixpKdr2
 hEjQ==
MIME-Version: 1.0
X-Received: by 10.180.103.193 with SMTP id fy1mr12683854wib.10.1387642926530; 
 Sat, 21 Dec 2013 08:22:06 -0800 (PST)
Received: by 10.216.127.68 with HTTP; Sat, 21 Dec 2013 08:22:06 -0800 (PST)
In-Reply-To: <83txe2aad0.fsf@HIDDEN>
References: <CAGVACNVfa8bvqHDOavzUzb6mGCxRHPzu2Pbv4Yi-76Ca+B_Rcw@HIDDEN>
 <83ob4cbvot.fsf@HIDDEN>
 <CAGVACNVaXbjPkm4YU3p+HhNxehJ-eBm1daPXuaBCRXfqM8zMTA@HIDDEN>
 <83txe2aad0.fsf@HIDDEN>
Date: Sat, 21 Dec 2013 18:22:06 +0200
Message-ID: <CAGVACNXijXM+dC396wou4WPvNRtK_4vyeQ7mcOHwjvttQjBwmg@HIDDEN>
From: Joan Karadimov <joan.karadimov@HIDDEN>
Content-Type: multipart/alternative; boundary=f46d04428e3ab606eb04ee0dcbc9
X-Spam-Score: -0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

--f46d04428e3ab606eb04ee0dcbc9
Content-Type: text/plain; charset=ISO-8859-1

> Unfortunately, taskkill is not available widely enough.  E.g., on my
> XP Home edition, it is not available, and I believe it is not there on
> systems older than XP, which we still support.

I am aware that 'taskkill' is not present on windowses (is that a word?)
older
than XP. This makes it no worse than 'CreateToolhelp32Snapshot'. But I din't
know of its absence from home editions. My first thought was to seek
inspiration
in the Wine project:
  (https://github.com/mirrors/wine/blob/master/programs/taskkill/taskkill.c)
... only to find:
  WINE_FIXME("/T not supported\n");
... so this seems like a dead end.

> This might be "good enough" -- we err on the safe side, and only leave
> some subprocesses not killed in rare situations.  Does this strategy
> solve the problem which started this bug report?  If so, please tell
> the main ideas of how you intend to avoid killing unrelated processes.

Here is some pseudo-code for it...

# This returns [a subset] of the edges in the process tree
def get-process-tree:
  1. let process-snapshot be the current process snapshot
  2. let process-tree be an empty list
  3. for parent-pid, child-pid in process-snapshot:
       if process-start-time(child-pid) < process-start-time(parent-pid):
         add(process-tree, (parent-pid . child-pid))

def kill-process-tree(root-process):
  1. open a process handle to the root-process (I am guessing that Emacs
already
     keeps a handle to all process it spawned so this step might be
unnecessary)
  2. let initial-process-tree be the return value of get-process-tree
  3. let inital-kill-list be the edges from initial-process-tree that are
     reachable from the root-process
  4. open process handles to every child-pid from inital-kill-list
  5. let revised-process-tree be the return value of get-process-tree
  6. let revised-kill-list be the intersection of inital-kill-list and
     revised-process-tree
  7. kill and close handles to child processes in final-kill-list
  8. close any remaining handles from step (4.)

There are a few non-obvious things here that need a skeptical reading.

The most arcane is that step (6.) in kill-process-tree really returns what
we
need to kill.

Other potential issue is the non-atomicity of step (4.) and the possibility
of
grabbing a handle to a process that wasn't in initial-process-tree. I claim
that
this is not an issue, because those will not end up in revised-kill-list.

Both, of course, I cannot prove formally. But so far I have been unable to
find
counterexamples.

--f46d04428e3ab606eb04ee0dcbc9
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>&gt; Unfortunately, taskkill is not available widely =
enough. =A0E.g., on my<br></div><div>&gt; XP Home edition, it is not availa=
ble, and I believe it is not there on<br>&gt; systems older than XP, which =
we still support.<br>
</div><div><br></div><div>I am aware that &#39;taskkill&#39; is not present=
 on windowses (is that a word?) older</div><div>than XP. This makes it no w=
orse than &#39;CreateToolhelp32Snapshot&#39;. But I din&#39;t</div><div>
know of its absence from home editions. My first thought was to seek inspir=
ation</div><div>in the Wine project:</div><div>=A0 (<a href=3D"https://gith=
ub.com/mirrors/wine/blob/master/programs/taskkill/taskkill.c">https://githu=
b.com/mirrors/wine/blob/master/programs/taskkill/taskkill.c</a>)</div>
<div>... only to find:</div><div>=A0 WINE_FIXME(&quot;/T not supported\n&qu=
ot;);</div><div>... so this seems like a dead end.</div><div><br></div><div=
>&gt; This might be &quot;good enough&quot; -- we err on the safe side, and=
 only leave<br>
&gt; some subprocesses not killed in rare situations. =A0Does this strategy=
<br>&gt; solve the problem which started this bug report? =A0If so, please =
tell<br>&gt; the main ideas of how you intend to avoid killing unrelated pr=
ocesses.<br>
</div><div><br></div><div>Here is some pseudo-code for it...</div><div><br>=
</div><div># This returns [a subset] of the edges in the process tree</div>=
<div>def get-process-tree:</div><div>=A0 1. let process-snapshot be the cur=
rent process snapshot</div>
<div>=A0 2. let process-tree be an empty list</div><div>=A0 3. for parent-p=
id, child-pid in process-snapshot:</div><div>=A0 =A0 =A0 =A0if process-star=
t-time(child-pid) &lt; process-start-time(parent-pid):</div><div>=A0 =A0 =
=A0 =A0 =A0add(process-tree, (parent-pid . child-pid))</div>
<div><br></div><div>def kill-process-tree(root-process):</div><div>=A0 1. o=
pen a process handle to the root-process (I am guessing that Emacs already<=
/div><div>=A0 =A0 =A0keeps a handle to all process it spawned so this step =
might be unnecessary)</div>
<div>=A0 2. let initial-process-tree be the return value of get-process-tre=
e</div><div>=A0 3. let inital-kill-list be the edges from initial-process-t=
ree that are</div><div>=A0 =A0 =A0reachable from the root-process</div><div=
>=A0 4. open process handles to every child-pid from inital-kill-list</div>
<div>=A0 5. let revised-process-tree be the return value of get-process-tre=
e</div><div>=A0 6. let revised-kill-list be the intersection of inital-kill=
-list and</div><div>=A0 =A0 =A0revised-process-tree</div><div>=A0 7. kill a=
nd close handles to child processes in final-kill-list</div>
<div>=A0 8. close any remaining handles from step (4.)</div><div><br></div>=
<div>There are a few non-obvious things here that need a skeptical reading.=
</div><div><br></div><div>The most arcane is that step (6.) in kill-process=
-tree really returns what we</div>
<div>need to kill.</div><div><br></div><div><div>Other potential issue is t=
he non-atomicity of step (4.) and the possibility of</div><div>grabbing a h=
andle to a process that wasn&#39;t in initial-process-tree. I claim that</d=
iv>
<div>this is not an issue, because those will not end up in revised-kill-li=
st.</div><div><br></div><div>Both, of course, I cannot prove formally. But =
so far I have been unable to find</div><div>counterexamples.</div></div>
<div><br></div></div>

--f46d04428e3ab606eb04ee0dcbc9--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#15983: 24.3; Emacs Not Killing Child Process
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 21 Dec 2013 18:39:02 +0000
Resent-Message-ID: <handler.15983.B15983.138765113130747 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 15983
X-GNU-PR-Package: emacs,w32
X-GNU-PR-Keywords: 
To: Joan Karadimov <joan.karadimov@HIDDEN>
Cc: bozhidar.batsov@HIDDEN, sjm@HIDDEN, 15983 <at> debbugs.gnu.org
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 15983-submit <at> debbugs.gnu.org id=B15983.138765113130747
          (code B ref 15983); Sat, 21 Dec 2013 18:39:02 +0000
Received: (at 15983) by debbugs.gnu.org; 21 Dec 2013 18:38:51 +0000
Received: from localhost ([127.0.0.1]:33506 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1VuRRq-0007zo-BB
	for submit <at> debbugs.gnu.org; Sat, 21 Dec 2013 13:38:50 -0500
Received: from mtaout22.012.net.il ([80.179.55.172]:56598)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <eliz@HIDDEN>) id 1VuRRm-0007za-Jl
 for 15983 <at> debbugs.gnu.org; Sat, 21 Dec 2013 13:38:48 -0500
Received: from conversion-daemon.a-mtaout22.012.net.il by
 a-mtaout22.012.net.il (HyperSendmail v2007.08) id
 <0MY6003005W5RA00@HIDDEN> for 15983 <at> debbugs.gnu.org;
 Sat, 21 Dec 2013 20:38:44 +0200 (IST)
Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il
 (HyperSendmail v2007.08) with ESMTPA id
 <0MY6003856GKO450@HIDDEN>;
 Sat, 21 Dec 2013 20:38:44 +0200 (IST)
Date: Sat, 21 Dec 2013 20:38:32 +0200
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <CAGVACNXijXM+dC396wou4WPvNRtK_4vyeQ7mcOHwjvttQjBwmg@HIDDEN>
X-012-Sender: halo1@HIDDEN
Message-id: <834n629hhz.fsf@HIDDEN>
References: <CAGVACNVfa8bvqHDOavzUzb6mGCxRHPzu2Pbv4Yi-76Ca+B_Rcw@HIDDEN>
 <83ob4cbvot.fsf@HIDDEN>
 <CAGVACNVaXbjPkm4YU3p+HhNxehJ-eBm1daPXuaBCRXfqM8zMTA@HIDDEN>
 <83txe2aad0.fsf@HIDDEN>
 <CAGVACNXijXM+dC396wou4WPvNRtK_4vyeQ7mcOHwjvttQjBwmg@HIDDEN>
X-Spam-Score: 2.2 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has
 identified this incoming email as possible spam.  The original message
 has been attached to this so you can view it (if it isn't spam) or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview:  > Date: Sat,
 21 Dec 2013 18:22:06 +0200 > From: Joan Karadimov
 <joan.karadimov@HIDDEN> > Cc: 15983 <at> debbugs.gnu.org,
 Simon Morgan <sjm@HIDDEN>, 
 > Bozhidar Batsov <bozhidar.batsov@HIDDEN> > > > Unfortunately, taskkill
 is not available widely enough. E.g., on my > > XP Home edition, it is not
 available, and I believe it is not there on > > systems older than XP, which
 we still support. > > I am aware that 'taskkill' is not present on windowses
 (is that a word?) > older than XP. This makes it no worse than
 'CreateToolhelp32Snapshot'. [...] 
 Content analysis details:   (2.2 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 1.2 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net
 [Blocked - see <http://www.spamcop.net/bl.shtml?80.179.55.172>]
 -0.0 RCVD_IN_DNSWL_NONE     RBL: Sender listed at http://www.dnswl.org/, no
 trust [80.179.55.172 listed in list.dnswl.org]
 1.0 SPF_SOFTFAIL           SPF: sender does not match SPF record (softfail)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 2.2 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has
 identified this incoming email as possible spam.  The original message
 has been attached to this so you can view it (if it isn't spam) or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 
 Content preview:  > Date: Sat, 21 Dec 2013 18:22:06 +0200 > From: Joan Karadimov
    <joan.karadimov@HIDDEN> > Cc: 15983 <at> debbugs.gnu.org, Simon Morgan <sjm@HIDDEN>,
    > Bozhidar Batsov <bozhidar.batsov@HIDDEN> > > > Unfortunately, taskkill
    is not available widely enough. E.g., on my > > XP Home edition, it is not
    available, and I believe it is not there on > > systems older than XP, which
    we still support. > > I am aware that 'taskkill' is not present on windowses
    (is that a word?) > older than XP. This makes it no worse than 'CreateToolhelp32Snapshot'.
    [...] 
 
 Content analysis details:   (2.2 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.0 RCVD_IN_DNSWL_NONE     RBL: Sender listed at http://www.dnswl.org/, no
                             trust
                             [80.179.55.172 listed in list.dnswl.org]
  1.2 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net
                [Blocked - see <http://www.spamcop.net/bl.shtml?80.179.55.172>]
  1.0 SPF_SOFTFAIL           SPF: sender does not match SPF record (softfail)

> Date: Sat, 21 Dec 2013 18:22:06 +0200
> From: Joan Karadimov <joan.karadimov@HIDDEN>
> Cc: 15983 <at> debbugs.gnu.org, Simon Morgan <sjm@HIDDEN>, 
> 	Bozhidar Batsov <bozhidar.batsov@HIDDEN>
> 
> > Unfortunately, taskkill is not available widely enough.  E.g., on my
> > XP Home edition, it is not available, and I believe it is not there on
> > systems older than XP, which we still support.
> 
> I am aware that 'taskkill' is not present on windowses (is that a word?)
> older than XP. This makes it no worse than 'CreateToolhelp32Snapshot'.

No, the toolhelp functions are available on Windows 2000 and even on
Windows 98.  They are unavailable only on NT 4.0.

> > This might be "good enough" -- we err on the safe side, and only leave
> > some subprocesses not killed in rare situations.  Does this strategy
> > solve the problem which started this bug report?

You didn't answer that question, but I assume the answer is YES.

>  If so, please tell
> > the main ideas of how you intend to avoid killing unrelated processes.
> 
> Here is some pseudo-code for it...
> 
> # This returns [a subset] of the edges in the process tree
> def get-process-tree:
>   1. let process-snapshot be the current process snapshot
>   2. let process-tree be an empty list
>   3. for parent-pid, child-pid in process-snapshot:
>        if process-start-time(child-pid) < process-start-time(parent-pid):
>          add(process-tree, (parent-pid . child-pid))

I think it would be better to also require that process-start-time is
before the time kill-process-tree is called.  This might miss some
children, if they happen to be spawned right after the call, but it is
safer.

Also, didn't you mean ">" in the above inequality?  A child process
cannot be born before its parent, right?  Or am I missing something?

> 
> def kill-process-tree(root-process):
>   1. open a process handle to the root-process (I am guessing that Emacs
> already
>      keeps a handle to all process it spawned so this step might be
> unnecessary)

Yes, Emacs already keeps a handle on each of its immediate child
processes.  That's how we know that those children exit.

> Other potential issue is the non-atomicity of step (4.) and the
> possibility of grabbing a handle to a process that wasn't in
> initial-process-tree. I claim that this is not an issue, because
> those will not end up in revised-kill-list.
> 
> Both, of course, I cannot prove formally. But so far I have been
> unable to find counterexamples.

The only thing that we should worry about is not to accidentally kill
unrelated processes.  Everything else is no worse than what we have
now.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#15983: 24.3; Emacs Not Killing Child Process
Resent-From: Joan Karadimov <joan.karadimov@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 22 Dec 2013 02:04:01 +0000
Resent-Message-ID: <handler.15983.B15983.138767779623383 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 15983
X-GNU-PR-Package: emacs,w32
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: Bozhidar Batsov <bozhidar.batsov@HIDDEN>, Simon Morgan <sjm@HIDDEN>, 15983 <at> debbugs.gnu.org
Received: via spool by 15983-submit <at> debbugs.gnu.org id=B15983.138767779623383
          (code B ref 15983); Sun, 22 Dec 2013 02:04:01 +0000
Received: (at 15983) by debbugs.gnu.org; 22 Dec 2013 02:03:16 +0000
Received: from localhost ([127.0.0.1]:33816 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1VuYNv-000653-9a
	for submit <at> debbugs.gnu.org; Sat, 21 Dec 2013 21:03:15 -0500
Received: from mail-wi0-f175.google.com ([209.85.212.175]:54149)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <joan.karadimov@HIDDEN>) id 1VuYNt-00064u-0Z
 for 15983 <at> debbugs.gnu.org; Sat, 21 Dec 2013 21:03:13 -0500
Received: by mail-wi0-f175.google.com with SMTP id hi5so9828223wib.14
 for <15983 <at> debbugs.gnu.org>; Sat, 21 Dec 2013 18:03:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=mime-version:in-reply-to:references:date:message-id:subject:from:to
 :cc:content-type;
 bh=NupJlcgl8ad/Y2npp7gd4JQaznuiLvyYn20pDmXynFo=;
 b=e6SJqoneWM7LUp1ZbSuCu4+irJmjZL2/hXkjKsuC4iGUEvx05t3/c2FFOOYGry1GEf
 ce0AyAEX0ywsmQ2NHbDN5aYTCANiuUvOGIo5swL6SMWH/z5o9fRnBaWPNWO9+YiCW0Pl
 eava0g6g2c7oMQbpWGhsd5xCa28yJ5SVTfxXQ1uWoiu4XA2r4v+N7XNombmQKGMLBiyB
 lACQxFLXr1JWU3GMQkPo4wOM+lIx8NNGGVBaHiRyXThV5zbbb96zxRy/kvf4tom13qqu
 sdKRwlN+bzET3FfqwFaA5hoM7ovGMblvsiyoEVHaxD8NtwIHniXny/oUsXPlKOk1DJsp
 FiAQ==
MIME-Version: 1.0
X-Received: by 10.180.103.193 with SMTP id fy1mr13904600wib.10.1387677792234; 
 Sat, 21 Dec 2013 18:03:12 -0800 (PST)
Received: by 10.216.127.68 with HTTP; Sat, 21 Dec 2013 18:03:12 -0800 (PST)
In-Reply-To: <834n629hhz.fsf@HIDDEN>
References: <CAGVACNVfa8bvqHDOavzUzb6mGCxRHPzu2Pbv4Yi-76Ca+B_Rcw@HIDDEN>
 <83ob4cbvot.fsf@HIDDEN>
 <CAGVACNVaXbjPkm4YU3p+HhNxehJ-eBm1daPXuaBCRXfqM8zMTA@HIDDEN>
 <83txe2aad0.fsf@HIDDEN>
 <CAGVACNXijXM+dC396wou4WPvNRtK_4vyeQ7mcOHwjvttQjBwmg@HIDDEN>
 <834n629hhz.fsf@HIDDEN>
Date: Sun, 22 Dec 2013 04:03:12 +0200
Message-ID: <CAGVACNUpYWH3RsxUHiqdNnc+WP5jwSU8MqmfP2Wm4KbmG7ZWKA@HIDDEN>
From: Joan Karadimov <joan.karadimov@HIDDEN>
Content-Type: multipart/alternative; boundary=f46d04428e3ade732004ee15e933
X-Spam-Score: -0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

--f46d04428e3ade732004ee15e933
Content-Type: text/plain; charset=ISO-8859-1

>
> > I am aware that 'taskkill' is not present on windowses (is that a word?)
> > older than XP. This makes it no worse than 'CreateToolhelp32Snapshot'.
>
> No, the toolhelp functions are available on Windows 2000 and even on
> Windows 98.  They are unavailable only on NT 4.0.
>
MSDN states that the "Minimum supported client" is XP. I guess 2000 is
counted with the server ones and 9x is not even considered.


> > > This might be "good enough" -- we err on the safe side, and only leave
> > > some subprocesses not killed in rare situations.  Does this strategy
> > > solve the problem which started this bug report?
>
> You didn't answer that question, but I assume the answer is YES.
>
It should fix the problem, yes. And it should be safe


> I think it would be better to also require that process-start-time is
> before the time kill-process-tree is called.  This might miss some
> children, if they happen to be spawned right after the call, but it is
> safer.
>
This should already be reflected in the requirement that all processes that
are killed were already in the initial-process-tree (the first snapshot).
But there is no harm in being more explicit about it in the code.

Also, didn't you mean ">" in the above inequality?  A child process
> cannot be born before its parent, right?  Or am I missing something?
>
Yes, of course. You are not missing anything.


> The only thing that we should worry about is not to accidentally kill
> unrelated processes.  Everything else is no worse than what we have
> now.
>
I'll start working on some code that I can show, then.

--f46d04428e3ade732004ee15e933
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddi=
ng-left:1ex">
<div class=3D"im">&gt; I am aware that &#39;taskkill&#39; is not present on=
 windowses (is that a word?)<br>
&gt; older than XP. This makes it no worse than &#39;CreateToolhelp32Snapsh=
ot&#39;.<br>
<br>
</div>No, the toolhelp functions are available on Windows 2000 and even on<=
br>
Windows 98. =A0They are unavailable only on NT 4.0.<br></blockquote><div>MS=
DN states that the &quot;Minimum supported client&quot; is XP. I guess 2000=
 is</div><div>counted with the server ones and 9x is not even considered.</=
div>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left=
-style:solid;padding-left:1ex">
<div class=3D"im">&gt; &gt; This might be &quot;good enough&quot; -- we err=
 on the safe side, and only leave<br>
&gt; &gt; some subprocesses not killed in rare situations. =A0Does this str=
ategy<br>
&gt; &gt; solve the problem which started this bug report?<br>
<br>
</div>You didn&#39;t answer that question, but I assume the answer is YES.<=
br></blockquote><div>It should fix the problem, yes. And it should be safe<=
/div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border=
-left-style:solid;padding-left:1ex">
I think it would be better to also require that process-start-time is<br>
before the time kill-process-tree is called. =A0This might miss some<br>
children, if they happen to be spawned right after the call, but it is<br>
safer.<br></blockquote><div><div>This should already be reflected in the re=
quirement that all processes that</div><div>are killed were already in the =
initial-process-tree (the first snapshot).</div><div>But there is no harm i=
n being more explicit about it in the code.</div>
</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);bord=
er-left-style:solid;padding-left:1ex">Also, didn&#39;t you mean &quot;&gt;&=
quot; in the above inequality? =A0A child process<br>

cannot be born before its parent, right? =A0Or am I missing something?<br><=
/blockquote><div>Yes, of course. You are not missing anything.</div><div>=
=A0=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-s=
tyle:solid;padding-left:1ex">

<div class=3D"im"><span style=3D"color:rgb(34,34,34)">The only thing that w=
e should worry about is not to accidentally kill</span><br></div>
unrelated processes. =A0Everything else is no worse than what we have<br>
now.<br>
</blockquote></div>I&#39;ll start working on some code that I can show, the=
n.</div></div>

--f46d04428e3ade732004ee15e933--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#15983: 24.3; Emacs Not Killing Child Process
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 22 Dec 2013 03:55:01 +0000
Resent-Message-ID: <handler.15983.B15983.13876844644033 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 15983
X-GNU-PR-Package: emacs,w32
X-GNU-PR-Keywords: 
To: Joan Karadimov <joan.karadimov@HIDDEN>
Cc: bozhidar.batsov@HIDDEN, sjm@HIDDEN, 15983 <at> debbugs.gnu.org
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 15983-submit <at> debbugs.gnu.org id=B15983.13876844644033
          (code B ref 15983); Sun, 22 Dec 2013 03:55:01 +0000
Received: (at 15983) by debbugs.gnu.org; 22 Dec 2013 03:54:24 +0000
Received: from localhost ([127.0.0.1]:33855 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1Vua7T-00012z-DS
	for submit <at> debbugs.gnu.org; Sat, 21 Dec 2013 22:54:23 -0500
Received: from mtaout20.012.net.il ([80.179.55.166]:61396)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <eliz@HIDDEN>) id 1Vua7Q-00012m-Hy
 for 15983 <at> debbugs.gnu.org; Sat, 21 Dec 2013 22:54:21 -0500
Received: from conversion-daemon.a-mtaout20.012.net.il by
 a-mtaout20.012.net.il (HyperSendmail v2007.08) id
 <0MY600C00W0CZD00@HIDDEN> for 15983 <at> debbugs.gnu.org;
 Sun, 22 Dec 2013 05:53:30 +0200 (IST)
Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il
 (HyperSendmail v2007.08) with ESMTPA id
 <0MY600C1HW55O380@HIDDEN>;
 Sun, 22 Dec 2013 05:53:30 +0200 (IST)
Date: Sun, 22 Dec 2013 05:53:18 +0200
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <CAGVACNUpYWH3RsxUHiqdNnc+WP5jwSU8MqmfP2Wm4KbmG7ZWKA@HIDDEN>
X-012-Sender: halo1@HIDDEN
Message-id: <83mwjt8rtd.fsf@HIDDEN>
References: <CAGVACNVfa8bvqHDOavzUzb6mGCxRHPzu2Pbv4Yi-76Ca+B_Rcw@HIDDEN>
 <83ob4cbvot.fsf@HIDDEN>
 <CAGVACNVaXbjPkm4YU3p+HhNxehJ-eBm1daPXuaBCRXfqM8zMTA@HIDDEN>
 <83txe2aad0.fsf@HIDDEN>
 <CAGVACNXijXM+dC396wou4WPvNRtK_4vyeQ7mcOHwjvttQjBwmg@HIDDEN>
 <834n629hhz.fsf@HIDDEN>
 <CAGVACNUpYWH3RsxUHiqdNnc+WP5jwSU8MqmfP2Wm4KbmG7ZWKA@HIDDEN>
X-Spam-Score: 2.2 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has
 identified this incoming email as possible spam.  The original message
 has been attached to this so you can view it (if it isn't spam) or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview:  > Date: Sun,
 22 Dec 2013 04:03:12 +0200 > From: Joan Karadimov
 <joan.karadimov@HIDDEN> > Cc: 15983 <at> debbugs.gnu.org,
 Simon Morgan <sjm@HIDDEN>, 
 > Bozhidar Batsov <bozhidar.batsov@HIDDEN> > > > > I am aware that
 'taskkill'
 is not present on windowses (is that a word?) > > > older than XP. This makes
 it no worse than 'CreateToolhelp32Snapshot'. > > > > No, the toolhelp functions
 are available on Windows 2000 and even on > > Windows 98. They are unavailable
 only on NT 4.0. > > > MSDN states that the "Minimum supported client" is
 XP. [...] 
 Content analysis details:   (2.2 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 1.2 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net
 [Blocked - see <http://www.spamcop.net/bl.shtml?80.179.55.166>]
 -0.0 RCVD_IN_DNSWL_NONE     RBL: Sender listed at http://www.dnswl.org/, no
 trust [80.179.55.166 listed in list.dnswl.org]
 1.0 SPF_SOFTFAIL           SPF: sender does not match SPF record (softfail)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 2.2 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has
 identified this incoming email as possible spam.  The original message
 has been attached to this so you can view it (if it isn't spam) or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 
 Content preview:  > Date: Sun, 22 Dec 2013 04:03:12 +0200 > From: Joan Karadimov
    <joan.karadimov@HIDDEN> > Cc: 15983 <at> debbugs.gnu.org, Simon Morgan <sjm@HIDDEN>,
    > Bozhidar Batsov <bozhidar.batsov@HIDDEN> > > > > I am aware that 'taskkill'
    is not present on windowses (is that a word?) > > > older than XP. This makes
    it no worse than 'CreateToolhelp32Snapshot'. > > > > No, the toolhelp functions
    are available on Windows 2000 and even on > > Windows 98. They are unavailable
    only on NT 4.0. > > > MSDN states that the "Minimum supported client" is
   XP. [...] 
 
 Content analysis details:   (2.2 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.0 RCVD_IN_DNSWL_NONE     RBL: Sender listed at http://www.dnswl.org/, no
                             trust
                             [80.179.55.166 listed in list.dnswl.org]
  1.2 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net
                [Blocked - see <http://www.spamcop.net/bl.shtml?80.179.55.166>]
  1.0 SPF_SOFTFAIL           SPF: sender does not match SPF record (softfail)

> Date: Sun, 22 Dec 2013 04:03:12 +0200
> From: Joan Karadimov <joan.karadimov@HIDDEN>
> Cc: 15983 <at> debbugs.gnu.org, Simon Morgan <sjm@HIDDEN>, 
> 	Bozhidar Batsov <bozhidar.batsov@HIDDEN>
> 
> > > I am aware that 'taskkill' is not present on windowses (is that a word?)
> > > older than XP. This makes it no worse than 'CreateToolhelp32Snapshot'.
> >
> > No, the toolhelp functions are available on Windows 2000 and even on
> > Windows 98.  They are unavailable only on NT 4.0.
> >
> MSDN states that the "Minimum supported client" is XP.

MSDN lies.  They do that in a lot of API functions, to pretend that
older versions don't exist (because their support has ended).

> I guess 2000 is counted with the server ones

No, it's not.

> and 9x is not even considered.

Right.

> > > > This might be "good enough" -- we err on the safe side, and only leave
> > > > some subprocesses not killed in rare situations.  Does this strategy
> > > > solve the problem which started this bug report?
> >
> > You didn't answer that question, but I assume the answer is YES.
> >
> It should fix the problem, yes.

Well, I'd prefer a test, to be sure.

> > I think it would be better to also require that process-start-time is
> > before the time kill-process-tree is called.  This might miss some
> > children, if they happen to be spawned right after the call, but it is
> > safer.
> >
> This should already be reflected in the requirement that all processes that
> are killed were already in the initial-process-tree (the first snapshot).

They could have been started before that.  E.g., imagine that one of
the children exited or died on its own, and its PID was reused, before
kill-process was called.

> I'll start working on some code that I can show, then.

Thank you.

Btw, if the patch is going to be substantial, we will need legal
paperwork from you, before we can accept the code.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#15983: 24.3; Emacs Not Killing Child Process
Resent-From: Joan Karadimov <joan.karadimov@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 23 Dec 2013 16:03:02 +0000
Resent-Message-ID: <handler.15983.B15983.138781453717313 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 15983
X-GNU-PR-Package: emacs,w32
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: Bozhidar Batsov <bozhidar.batsov@HIDDEN>, Simon Morgan <sjm@HIDDEN>, 15983 <at> debbugs.gnu.org
Received: via spool by 15983-submit <at> debbugs.gnu.org id=B15983.138781453717313
          (code B ref 15983); Mon, 23 Dec 2013 16:03:02 +0000
Received: (at 15983) by debbugs.gnu.org; 23 Dec 2013 16:02:17 +0000
Received: from localhost ([127.0.0.1]:36073 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1Vv7xQ-0004VA-4G
	for submit <at> debbugs.gnu.org; Mon, 23 Dec 2013 11:02:16 -0500
Received: from mail-we0-f169.google.com ([74.125.82.169]:35072)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <joan.karadimov@HIDDEN>) id 1Vv7xN-0004Ux-BS
 for 15983 <at> debbugs.gnu.org; Mon, 23 Dec 2013 11:02:13 -0500
Received: by mail-we0-f169.google.com with SMTP id w61so5131905wes.0
 for <15983 <at> debbugs.gnu.org>; Mon, 23 Dec 2013 08:02:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=mime-version:in-reply-to:references:date:message-id:subject:from:to
 :cc:content-type;
 bh=tY45GmRXMu518FB6wjiYFeoZcTpLWROLRykIMqG/ulM=;
 b=0RPCLQJTXKrrgyuGfYXatFf9ESgWqHFgJENDVrUa7y+12gTYfdZklh2pzzV7q/lKam
 lwjk8BMmdC/XthFgC6tsY7RDtxfgqQ5FpzqFeRuf2zjKU6c+hqIIf/RKjoHqAt0DKshO
 vcJSDDyRv7okKFFSql0O3t7yiEhYnc0D95R7CyzvGAfpKXbDbL/7YWaRRRn5tfT9O9iT
 GNCpko+rJZqXilMChp21KRB47xWXnh2ZEZagIxXLfl8N/0ttb0u1UvREj748Hus6AgT/
 k0v7YwWacB99F/zWN/fIl7p35KDsg3BZ1Q8Hnn9mACG8zUJ4lg62FwAwGaLjt2RL2qhI
 2/Bw==
MIME-Version: 1.0
X-Received: by 10.180.79.38 with SMTP id g6mr18787309wix.60.1387814532307;
 Mon, 23 Dec 2013 08:02:12 -0800 (PST)
Received: by 10.216.127.68 with HTTP; Mon, 23 Dec 2013 08:02:12 -0800 (PST)
In-Reply-To: <83mwjt8rtd.fsf@HIDDEN>
References: <CAGVACNVfa8bvqHDOavzUzb6mGCxRHPzu2Pbv4Yi-76Ca+B_Rcw@HIDDEN>
 <83ob4cbvot.fsf@HIDDEN>
 <CAGVACNVaXbjPkm4YU3p+HhNxehJ-eBm1daPXuaBCRXfqM8zMTA@HIDDEN>
 <83txe2aad0.fsf@HIDDEN>
 <CAGVACNXijXM+dC396wou4WPvNRtK_4vyeQ7mcOHwjvttQjBwmg@HIDDEN>
 <834n629hhz.fsf@HIDDEN>
 <CAGVACNUpYWH3RsxUHiqdNnc+WP5jwSU8MqmfP2Wm4KbmG7ZWKA@HIDDEN>
 <83mwjt8rtd.fsf@HIDDEN>
Date: Mon, 23 Dec 2013 18:02:12 +0200
Message-ID: <CAGVACNW6sTouWp98PTK5HVJ27_0LoXuvGVU+t3JSdpV-D1rDSQ@HIDDEN>
From: Joan Karadimov <joan.karadimov@HIDDEN>
Content-Type: multipart/alternative; boundary=f46d044287f63663ca04ee35c0ad
X-Spam-Score: -0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

--f46d044287f63663ca04ee35c0ad
Content-Type: text/plain; charset=ISO-8859-1

>
> > > > > This might be "good enough" -- we err on the safe side, and only
> leave
> > > > > some subprocesses not killed in rare situations.  Does this
> strategy
> > > > > solve the problem which started this bug report?
> > >
> > > You didn't answer that question, but I assume the answer is YES.
> > >
> > It should fix the problem, yes.
>
> Well, I'd prefer a test, to be sure.
>
> Next few days I will be spending less time on this. I'll have something
testable
a few days after Christmas.

Btw, if the patch is going to be substantial, we will need legal
> paperwork from you, before we can accept the code.
>
Yes, I know. This is forming to be larger than I initially thought. Maybe
once
I am done we can evaluate just how big the change set is and I'll do the
paperwork if needed.

--f46d044287f63663ca04ee35c0ad
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddi=
ng-left:1ex">
<div class=3D"im">&gt; &gt; &gt; &gt; This might be &quot;good enough&quot;=
 -- we err on the safe side, and only leave<br>
&gt; &gt; &gt; &gt; some subprocesses not killed in rare situations. =A0Doe=
s this strategy<br>
&gt; &gt; &gt; &gt; solve the problem which started this bug report?<br>
&gt; &gt;<br>
&gt; &gt; You didn&#39;t answer that question, but I assume the answer is Y=
ES.<br>
&gt; &gt;<br>
&gt; It should fix the problem, yes.<br>
<br>
</div>Well, I&#39;d prefer a test, to be sure.<br>
<div class=3D"im"><br></div></blockquote><div>Next few days I will be spend=
ing less time on this. I&#39;ll have something testable</div><div>a few day=
s after Christmas.</div><div><br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb=
(204,204,204);border-left-style:solid;padding-left:1ex">
Btw, if the patch is going to be substantial, we will need legal<br>
paperwork from you, before we can accept the code.<br>
</blockquote></div></div><div class=3D"gmail_extra"><div>Yes, I know. This =
is forming to be larger than I initially thought. Maybe once</div><div>I am=
 done we can evaluate just how big the change set is and I&#39;ll do the</d=
iv>
<div>paperwork if needed.</div><div><br></div></div></div>

--f46d044287f63663ca04ee35c0ad--

Last modified: Mon, 25 Nov 2019 12:00:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.