Received: (at 15983) by debbugs.gnu.org; 23 Dec 2013 16:02:17 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Dec 23 11:02:16 2013 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> Subject: Re: bug#15983: 24.3; Emacs Not Killing Child Process From: Joan Karadimov <joan.karadimov@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Content-Type: multipart/alternative; boundary=f46d044287f63663ca04ee35c0ad X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 15983 Cc: Bozhidar Batsov <bozhidar.batsov@HIDDEN>, Simon Morgan <sjm@HIDDEN>, 15983 <at> debbugs.gnu.org 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">> > > > This might be "good enough"= -- we err on the safe side, and only leave<br> > > > > some subprocesses not killed in rare situations. =A0Doe= s this strategy<br> > > > > solve the problem which started this bug report?<br> > ><br> > > You didn't answer that question, but I assume the answer is Y= ES.<br> > ><br> > It should fix the problem, yes.<br> <br> </div>Well, I'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'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'll do the</d= iv> <div>paperwork if needed.</div><div><br></div></div></div> --f46d044287f63663ca04ee35c0ad--
bug-gnu-emacs@HIDDEN:bug#15983; Package emacs,w32.
Full text available.
Received: (at 15983) by debbugs.gnu.org; 22 Dec 2013 03:54:24 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Dec 21 22:54:24 2013
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>
Subject: Re: bug#15983: 24.3; Emacs Not Killing Child Process
In-reply-to: <CAGVACNUpYWH3RsxUHiqdNnc+WP5jwSU8MqmfP2Wm4KbmG7ZWKA@HIDDEN>
X-012-Sender: halo1@HIDDEN
To: Joan Karadimov <joan.karadimov@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-Debbugs-Envelope-To: 15983
Cc: bozhidar.batsov@HIDDEN, sjm@HIDDEN, 15983 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Eli Zaretskii <eliz@HIDDEN>
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.
bug-gnu-emacs@HIDDEN:bug#15983; Package emacs,w32.
Full text available.Received: (at 15983) by debbugs.gnu.org; 22 Dec 2013 02:03:16 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Dec 21 21:03:15 2013 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> Subject: Re: bug#15983: 24.3; Emacs Not Killing Child Process From: Joan Karadimov <joan.karadimov@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Content-Type: multipart/alternative; boundary=f46d04428e3ade732004ee15e933 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 15983 Cc: Bozhidar Batsov <bozhidar.batsov@HIDDEN>, Simon Morgan <sjm@HIDDEN>, 15983 <at> debbugs.gnu.org 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">> I am aware that 'taskkill' is not present on= windowses (is that a word?)<br> > older than XP. This makes it no worse than 'CreateToolhelp32Snapsh= ot'.<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 "Minimum supported client" 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">> > This might be "good enough" -- we err= on the safe side, and only leave<br> > > some subprocesses not killed in rare situations. =A0Does this str= ategy<br> > > solve the problem which started this bug report?<br> <br> </div>You didn'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't you mean ">&= 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'll start working on some code that I can show, the= n.</div></div> --f46d04428e3ade732004ee15e933--
bug-gnu-emacs@HIDDEN:bug#15983; Package emacs,w32.
Full text available.
Received: (at 15983) by debbugs.gnu.org; 21 Dec 2013 18:38:51 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Dec 21 13:38:51 2013
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>
Subject: Re: bug#15983: 24.3; Emacs Not Killing Child Process
In-reply-to: <CAGVACNXijXM+dC396wou4WPvNRtK_4vyeQ7mcOHwjvttQjBwmg@HIDDEN>
X-012-Sender: halo1@HIDDEN
To: Joan Karadimov <joan.karadimov@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-Debbugs-Envelope-To: 15983
Cc: bozhidar.batsov@HIDDEN, sjm@HIDDEN, 15983 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Eli Zaretskii <eliz@HIDDEN>
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.
bug-gnu-emacs@HIDDEN:bug#15983; Package emacs,w32.
Full text available.
Received: (at 15983) by debbugs.gnu.org; 21 Dec 2013 16:22:11 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Dec 21 11:22:10 2013
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>
Subject: Re: bug#15983: 24.3; Emacs Not Killing Child Process
From: Joan Karadimov <joan.karadimov@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Content-Type: multipart/alternative; boundary=f46d04428e3ab606eb04ee0dcbc9
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 15983
Cc: Bozhidar Batsov <bozhidar.batsov@HIDDEN>, Simon Morgan <sjm@HIDDEN>,
15983 <at> debbugs.gnu.org
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>> Unfortunately, taskkill is not available widely =
enough. =A0E.g., on my<br></div><div>> XP Home edition, it is not availa=
ble, and I believe it is not there on<br>> systems older than XP, which =
we still support.<br>
</div><div><br></div><div>I am aware that 'taskkill' is not present=
on windowses (is that a word?) older</div><div>than XP. This makes it no w=
orse than 'CreateToolhelp32Snapshot'. But I din'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("/T not supported\n&qu=
ot;);</div><div>... so this seems like a dead end.</div><div><br></div><div=
>> This might be "good enough" -- we err on the safe side, and=
only leave<br>
> some subprocesses not killed in rare situations. =A0Does this strategy=
<br>> solve the problem which started this bug report? =A0If so, please =
tell<br>> 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) < 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'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--
bug-gnu-emacs@HIDDEN:bug#15983; Package emacs,w32.
Full text available.
Received: (at 15983) by debbugs.gnu.org; 21 Dec 2013 08:15:47 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Dec 21 03:15:47 2013
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>
Subject: Re: bug#15983: 24.3; Emacs Not Killing Child Process
In-reply-to: <CAGVACNVaXbjPkm4YU3p+HhNxehJ-eBm1daPXuaBCRXfqM8zMTA@HIDDEN>
X-012-Sender: halo1@HIDDEN
To: Joan Karadimov <joan.karadimov@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-Debbugs-Envelope-To: 15983
Cc: bozhidar.batsov@HIDDEN, sjm@HIDDEN, 15983 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Eli Zaretskii <eliz@HIDDEN>
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.
bug-gnu-emacs@HIDDEN:bug#15983; Package emacs,w32.
Full text available.
Received: (at 15983) by debbugs.gnu.org; 20 Dec 2013 22:28:08 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Dec 20 17:28:08 2013
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>
Subject: Re: bug#15983: 24.3; Emacs Not Killing Child Process
From: Joan Karadimov <joan.karadimov@HIDDEN>
To: bug-gnu-emacs@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, 15983 <at> debbugs.gnu.org
Content-Type: multipart/alternative; boundary=f46d043c80cc8f63c904edfecad4
X-Spam-Score: 0.3 (/)
X-Debbugs-Envelope-To: 15983
Cc: Bozhidar Batsov <bozhidar.batsov@HIDDEN>, Simon Morgan <sjm@HIDDEN>
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 "performace=
" part of the</div>
<div>issues.</div><div><br></div><div>Back to the main issue - I wasn't=
aware that pid'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("taskkill /PID XXXX /T")</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"><<a href=3D"mailto:=
eliz@HIDDEN" target=3D"_blank">eliz@HIDDEN</a>></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">> Date: Thu, 19 Dec 2013 17:44:37 +0200<br>
> From: Joan Karadimov <<a href=3D"mailto:joan.karadimov@HIDDEN" t=
arget=3D"_blank">joan.karadimov@HIDDEN</a>><br>
> 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 <<a href=3D"mailto:bozhidar.batsov@HIDDEN" target=3D"_blank">b=
ozhidar.batsov@HIDDEN</a>><br>
<div>><br>
> > Emacs on Windows can only monitor and kill its immediate subproce=
sses,<br>
> > 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.<br>
> 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<br>
> and kills all child processes (as long as pid<0). I did some sanity=
<br>
> testing and it works.<br>
<br>
</div>Thanks, but I don't think we can use this code safely: there'=
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'm<br=
>
afraid we will need to live with this some more.<br>
<div><br>
> - there is no OS detection - this will get ugly on Windows 9x and<br>
> 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>
> - performance: 3 API calls are made for each descendant<br>
> process. This can be reduced to a total 3 calls (regardless of the<br>
> 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--
bug-gnu-emacs@HIDDEN:bug#15983; Package emacs,w32.
Full text available.
Received: (at submit) by debbugs.gnu.org; 20 Dec 2013 22:28:12 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Dec 20 17:28:12 2013
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>
Subject: Re: bug#15983: 24.3; Emacs Not Killing Child Process
From: Joan Karadimov <joan.karadimov@HIDDEN>
To: bug-gnu-emacs@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, 15983 <at> debbugs.gnu.org
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-Debbugs-Envelope-To: submit
Cc: Bozhidar Batsov <bozhidar.batsov@HIDDEN>, Simon Morgan <sjm@HIDDEN>
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 "performace=
" part of the</div>
<div>issues.</div><div><br></div><div>Back to the main issue - I wasn't=
aware that pid'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("taskkill /PID XXXX /T")</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"><<a href=3D"mailto:=
eliz@HIDDEN" target=3D"_blank">eliz@HIDDEN</a>></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">> Date: Thu, 19 Dec 2013 17:44:37 +0200<br>
> From: Joan Karadimov <<a href=3D"mailto:joan.karadimov@HIDDEN" t=
arget=3D"_blank">joan.karadimov@HIDDEN</a>><br>
> 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 <<a href=3D"mailto:bozhidar.batsov@HIDDEN" target=3D"_blank">b=
ozhidar.batsov@HIDDEN</a>><br>
<div>><br>
> > Emacs on Windows can only monitor and kill its immediate subproce=
sses,<br>
> > 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.<br>
> 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<br>
> and kills all child processes (as long as pid<0). I did some sanity=
<br>
> testing and it works.<br>
<br>
</div>Thanks, but I don't think we can use this code safely: there'=
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'm<br=
>
afraid we will need to live with this some more.<br>
<div><br>
> - there is no OS detection - this will get ugly on Windows 9x and<br>
> 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>
> - performance: 3 API calls are made for each descendant<br>
> process. This can be reduced to a total 3 calls (regardless of the<br>
> 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--
bug-gnu-emacs@HIDDEN:bug#15983; Package emacs,w32.
Full text available.Received: (at submit) by debbugs.gnu.org; 19 Dec 2013 17:24:43 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Dec 19 12:24:43 2013 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> Subject: Re: bug#15983: 24.3; Emacs Not Killing Child Process In-reply-to: <CAGVACNVfa8bvqHDOavzUzb6mGCxRHPzu2Pbv4Yi-76Ca+B_Rcw@HIDDEN> X-012-Sender: halo1@HIDDEN To: Joan Karadimov <joan.karadimov@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-Debbugs-Envelope-To: submit Cc: bozhidar.batsov@HIDDEN, bug-gnu-emacs@HIDDEN, sjm@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii <eliz@HIDDEN> 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.
bug-gnu-emacs@HIDDEN:bug#15983; Package emacs,w32.
Full text available.Received: (at submit) by debbugs.gnu.org; 19 Dec 2013 16:52:42 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Dec 19 11:52:42 2013 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> Subject: bug#15983: 24.3; Emacs Not Killing Child Process From: Joan Karadimov <joan.karadimov@HIDDEN> To: bug-gnu-emacs@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-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Thu, 19 Dec 2013 11:52:40 -0500 Cc: Bozhidar Batsov <bozhidar.batsov@HIDDEN>, eliz@HIDDEN, sjm@HIDDEN 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)">> Emacs on Windows= can only monitor and kill its immediate subprocesses, > it cannot monitor, let alone kill, any of their descendant processes, <span style=3D"font-family:arial">> </span>because it has no idea about = them. And the OS doesn't automatically <span style=3D"font-family:arial">> </span>kill all the processes in the= subprocess tree, and there's no way to <span style=3D"font-family:arial">> </span>send a signal to them all, as= on Posix platforms. If killing the <span style=3D"font-family:arial">> </span>immediate child process doesn= 't cause some of its children to exit or <span style=3D"font-family:arial">> </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'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.</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'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--
bug-gnu-emacs@HIDDEN:bug#15983; Package emacs,w32.
Full text available.
Received: (at 15983) by debbugs.gnu.org; 19 Dec 2013 15:56:54 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Dec 19 10:56:54 2013
Received: from localhost ([127.0.0.1]:58801 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.80)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1Vtfy1-0001xi-Pb
for submit <at> debbugs.gnu.org; Thu, 19 Dec 2013 10:56:54 -0500
Received: from mail-ea0-f182.google.com ([209.85.215.182]:64360)
by debbugs.gnu.org with esmtp (Exim 4.80)
(envelope-from <bozhidar.batsov@HIDDEN>) id 1Vtfxy-0001xZ-Ty
for 15983 <at> debbugs.gnu.org; Thu, 19 Dec 2013 10:56:51 -0500
Received: by mail-ea0-f182.google.com with SMTP id a15so571321eae.41
for <15983 <at> debbugs.gnu.org>; Thu, 19 Dec 2013 07:56:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=date:from:to:message-id:in-reply-to:references:subject:mime-version
:content-type; bh=0KDGylb7/hRgBP/y03MUoiVBHKOdnq6UVpnkx+TC+pY=;
b=R5eatVvBSj9/tm3m19wbKbLbhguoRbSPPfPU4UkfU0KOFzA7+E9hHzxGRN6IbG5Q9P
OhN4kVmDYkkYwIZnAUQOJGFwmsJGZcq+c3i29L4O5rppSCXOrqqZ7rPpH5DdFMP05Eku
TnbJVYhisAwkEy3/JwgLswCx9PqO0KJLkyMHimkGJmbHaToujyYzVPjMpWDB35od1z9L
+/lGhxROB8xXx4yEokWgSVw7FduDZuVI+9INynMuY+D73cvjKwDTv6rrX+v/lZE5LTve
3J/pNlax8uZT/5w4wX0e477gvTOgZzAbsa7Ida3DQMTdPRCg58G+uVDW+TXmRkz9LmBU
cVpw==
X-Received: by 10.14.7.2 with SMTP id 2mr551016eeo.16.1387468609817;
Thu, 19 Dec 2013 07:56:49 -0800 (PST)
Received: from [192.168.1.28] ([95.87.231.111])
by mx.google.com with ESMTPSA id n1sm10434972eep.20.2013.12.19.07.56.48
for <15983 <at> debbugs.gnu.org>
(version=TLSv1 cipher=RC4-SHA bits=128/128);
Thu, 19 Dec 2013 07:56:48 -0800 (PST)
Date: Thu, 19 Dec 2013 17:56:46 +0200
From: Bozhidar Batsov <bozhidar.batsov@HIDDEN>
To: 15983 <at> debbugs.gnu.org
Message-ID: <D55B149A712C44658EBA327A9B8D664F@HIDDEN>
In-Reply-To: <CAGVACNVfa8bvqHDOavzUzb6mGCxRHPzu2Pbv4Yi-76Ca+B_Rcw@HIDDEN>
References: <CAGVACNVfa8bvqHDOavzUzb6mGCxRHPzu2Pbv4Yi-76Ca+B_Rcw@HIDDEN>
Subject: Fw: bug#15983: 24.3; Emacs Not Killing Child Process
X-Mailer: sparrow 1.6.4 (build 1178)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="52b3173e_52d7b105_1c26"
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 15983
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 (/)
--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 <joan.karadimov=40=
gmail.com><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 <bozhidar.batsov=40gmail.com><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>> Emacs on Windows can only monitor and kill it=
s immediate subprocesses,
> it cannot monitor, let alone kill, any of their descendant processes=
,
<span style=3D=22font-family:arial=22>> </span>because it has no idea =
about them. And the OS doesn't automatically
<span style=3D=22font-family:arial=22>> </span>kill all the processes =
in the subprocess tree, and there's no way to
<span style=3D=22font-family:arial=22>> </span>send a signal to them a=
ll, as on Posix platforms. If killing the
<span style=3D=22font-family:arial=22>> </span>immediate child process=
doesn't cause some of its children to exit or
<span style=3D=22font-family:arial=22>> </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<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--
bug-gnu-emacs@HIDDEN:bug#15983; Package emacs,w32.
Full text available.Received: (at 15983) by debbugs.gnu.org; 27 Nov 2013 21:02:52 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Nov 27 16:02:52 2013 Received: from localhost ([127.0.0.1]:48075 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1VlmG3-0004tM-KG for submit <at> debbugs.gnu.org; Wed, 27 Nov 2013 16:02:51 -0500 Received: from mtaout22.012.net.il ([80.179.55.172]:51113) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from <eliz@HIDDEN>) id 1VlmG0-0004t5-5g for 15983 <at> debbugs.gnu.org; Wed, 27 Nov 2013 16:02:49 -0500 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MWX00M00WR2QU00@HIDDEN> for 15983 <at> debbugs.gnu.org; Wed, 27 Nov 2013 23:02:41 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MWX00MR8X4GID80@HIDDEN>; Wed, 27 Nov 2013 23:02:41 +0200 (IST) Date: Wed, 27 Nov 2013 23:02:35 +0200 From: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#15983: 24.3; Emacs Not Killing Child Process In-reply-to: <87zjop3fet.fsf@HIDDEN> X-012-Sender: halo1@HIDDEN To: sjm@HIDDEN Message-id: <8338mha784.fsf@HIDDEN> References: <87zjop3fet.fsf@HIDDEN> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 15983 Cc: 15983 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii <eliz@HIDDEN> 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: 1.0 (+) > 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.
bug-gnu-emacs@HIDDEN:bug#15983; Package emacs.
Full text available.
Received: (at submit) by debbugs.gnu.org; 27 Nov 2013 17:49:48 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Nov 27 12:49:48 2013
Received: from localhost ([127.0.0.1]:47978 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.80)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1VljFD-0008Qb-Tp
for submit <at> debbugs.gnu.org; Wed, 27 Nov 2013 12:49:48 -0500
Received: from eggs.gnu.org ([208.118.235.92]:37534)
by debbugs.gnu.org with esmtp (Exim 4.80)
(envelope-from <sjm@HIDDEN>) id 1VljDr-0008Nw-6t
for submit <at> debbugs.gnu.org; Wed, 27 Nov 2013 12:48:24 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
(envelope-from <sjm@HIDDEN>) id 1VljDc-0005fu-9z
for submit <at> debbugs.gnu.org; Wed, 27 Nov 2013 12:48:17 -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 autolearn=disabled
version=3.3.2
Received: from lists.gnu.org ([2001:4830:134:3::11]:41381)
by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <sjm@HIDDEN>)
id 1VljDc-0005ff-6f
for submit <at> debbugs.gnu.org; Wed, 27 Nov 2013 12:48:08 -0500
Received: from eggs.gnu.org ([2001:4830:134:3::10]:39162)
by lists.gnu.org with esmtp (Exim 4.71) (envelope-from <sjm@HIDDEN>)
id 1VljDU-0002rX-Q4
for bug-gnu-emacs@HIDDEN; Wed, 27 Nov 2013 12:48:08 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
(envelope-from <sjm@HIDDEN>) id 1VljDM-0005cG-RL
for bug-gnu-emacs@HIDDEN; Wed, 27 Nov 2013 12:48:00 -0500
Received: from 95.172.255.103.ip.static.xcl.net.uk ([95.172.255.103]:47906
helo=out-1.mail.mhd.uk.as44574.net)
by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <sjm@HIDDEN>)
id 1VljDM-0005c8-J3
for bug-gnu-emacs@HIDDEN; Wed, 27 Nov 2013 12:47:52 -0500
Received: from lambda.drguildo.com ([212.105.161.183] helo=SIMON-PC)
by out-1.mail.mhd.uk.as44574.net with esmtp (Exim 4.72)
(envelope-from <sjm@HIDDEN>) id 1VljAL-0004QF-IX
for bug-gnu-emacs@HIDDEN; Wed, 27 Nov 2013 17:44:45 +0000
From: sjm@HIDDEN
To: bug-gnu-emacs@HIDDEN
Subject: 24.3; Emacs Not Killing Child Process
Date: Wed, 27 Nov 2013 17:47:38 +0000
Message-ID: <87zjop3fet.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic]
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.0 (-----)
X-Debbugs-Envelope-To: submit
X-Mailman-Approved-At: Wed, 27 Nov 2013 12:49:46 -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: -5.0 (-----)
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)
sjm@HIDDEN:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#15983; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.