GNU bug report logs - #15983
24.3; Emacs Not Killing Child Process

Previous Next

Package: emacs;

Reported by: sjm <at> sjm.io

Date: Wed, 27 Nov 2013 17:50:02 UTC

Severity: minor

Found in version 24.3

Full log


Message #20 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Joan Karadimov <joan.karadimov <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org, Eli Zaretskii <eliz <at> gnu.org>, 15983 <at> debbugs.gnu.org
Cc: Bozhidar Batsov <bozhidar.batsov <at> gmail.com>, Simon Morgan <sjm <at> sjm.io>
Subject: Re: bug#15983: 24.3; Emacs Not Killing Child Process
Date: Sat, 21 Dec 2013 00:28:02 +0200
[Message part 1 (text/plain, inline)]
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 <at> gnu.org> wrote:

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

This bug report was last modified 11 years and 175 days ago.

Previous Next


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