From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Joan Karadimov Newsgroups: gmane.emacs.bugs Subject: bug#15983: 24.3; Emacs Not Killing Child Process Date: Sat, 21 Dec 2013 00:28:02 +0200 Message-ID: References: <83ob4cbvot.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=f46d043c80cc8f63c904edfecad4 X-Trace: ger.gmane.org 1387578548 9695 80.91.229.3 (20 Dec 2013 22:29:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 20 Dec 2013 22:29:08 +0000 (UTC) Cc: Simon Morgan , Bozhidar Batsov To: 15983@debbugs.gnu.org, eliz@gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Dec 20 23:29:11 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Vu8ZB-0004U0-Px for geb-bug-gnu-emacs@m.gmane.org; Fri, 20 Dec 2013 23:29:10 +0100 Original-Received: from localhost ([::1]:52138 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vu8ZB-0004Jm-98 for geb-bug-gnu-emacs@m.gmane.org; Fri, 20 Dec 2013 17:29:09 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33485) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vu8Z6-0004JQ-Es for bug-gnu-emacs@gnu.org; Fri, 20 Dec 2013 17:29:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vu8Z4-0007fy-QV for bug-gnu-emacs@gnu.org; Fri, 20 Dec 2013 17:29:04 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:46515) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vu8Z4-0007fu-NA for bug-gnu-emacs@gnu.org; Fri, 20 Dec 2013 17:29:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Vu8Z4-0002Ha-9O for bug-gnu-emacs@gnu.org; Fri, 20 Dec 2013 17:29:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Joan Karadimov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 20 Dec 2013 22:29:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15983 X-GNU-PR-Package: emacs,w32 X-GNU-PR-Keywords: X-Debbugs-Original-To: bug-gnu-emacs@gnu.org, Eli Zaretskii , 15983@debbugs.gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.13875784928701 (code B ref -1); Fri, 20 Dec 2013 22:29:02 +0000 Original-Received: (at submit) by debbugs.gnu.org; 20 Dec 2013 22:28:12 +0000 Original-Received: from localhost ([127.0.0.1]:60534 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vu8YG-0002GG-0M for submit@debbugs.gnu.org; Fri, 20 Dec 2013 17:28:12 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:59876) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vu8YD-0002G7-G7 for submit@debbugs.gnu.org; Fri, 20 Dec 2013 17:28:10 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vu8YB-0007YY-IP for submit@debbugs.gnu.org; Fri, 20 Dec 2013 17:28:09 -0500 Original-Received: from lists.gnu.org ([2001:4830:134:3::11]:50470) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vu8YB-0007YU-Ev for submit@debbugs.gnu.org; Fri, 20 Dec 2013 17:28:07 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33358) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vu8YA-0004H2-3j for bug-gnu-emacs@gnu.org; Fri, 20 Dec 2013 17:28:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vu8Y8-0007YF-OX for bug-gnu-emacs@gnu.org; Fri, 20 Dec 2013 17:28:06 -0500 Original-Received: from mail-we0-x22b.google.com ([2a00:1450:400c:c03::22b]:39212) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vu8Y8-0007Y7-B1; Fri, 20 Dec 2013 17:28:04 -0500 Original-Received: by mail-we0-f171.google.com with SMTP id q58so3101689wes.16 for ; 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== X-Received: by 10.180.24.99 with SMTP id t3mr9938666wif.1.1387578482711; Fri, 20 Dec 2013 14:28:02 -0800 (PST) Original-Received: by 10.216.127.68 with HTTP; Fri, 20 Dec 2013 14:28:02 -0800 (PST) In-Reply-To: <83ob4cbvot.fsf@gnu.org> 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-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:82305 Archived-At: --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 wrote: > > Date: Thu, 19 Dec 2013 17:44:37 +0200 > > From: Joan Karadimov > > Cc: sjm@sjm.io, eliz@gnu.org, Bozhidar Batsov > > > > > > 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
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 ha= ve no idea how to
put it together.

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

Now I am starti= ng to think in another direction. Would something like:
=A0 syste= m("taskkill /PID XXXX /T")
... be an acceptable solutio= n?

On Thu, Dec = 19, 2013 at 7:24 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> Date: Thu, 19 Dec 2013 17:44:37 +0200
> From: Joan Karadimov <joan.karadimov@gmail.com>
> Cc: sjm@sjm.io, eliz@gnu.org, Bozhidar = Batsov <b= ozhidar.batsov@gmail.com>
>
> > Emacs on Windows can only monitor and kill its immediate subproce= sses,
> > it cannot monitor, let alone kill, any of their descendant proces= ses,> because it has no idea about them. =A0And the OS doesn't autom= atically> kill all the processes in the subprocess tree, and there's= no way to> send a signal to them all, as on Posix platforms. =A0If kill= ing 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<= br> > 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. =A0During 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. =A0But such a strategy would
require some kind of notification to Emacs from its subprocesses when
they launch their subprocesses. =A0If you (or someone else) know how to
set this up, we could indeed resolve this problem. =A0Otherwise, 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<= br> 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--