This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 138116 - Stopping a running app doesn't stop the child process
Summary: Stopping a running app doesn't stop the child process
Alias: None
Product: platform
Classification: Unclassified
Component: Execution (show other bugs)
Version: 6.x
Hardware: PC Windows XP
: P2 blocker (vote)
Assignee: Petr Hejl
Depends on: 195537
  Show dependency tree
Reported: 2008-06-24 16:37 UTC by bkwillis
Modified: 2011-02-16 16:53 UTC (History)
6 users (show)

See Also:
Exception Reporter:

the patch (using winp) (15.10 KB, text/plain)
2008-07-11 16:00 UTC, Petr Hejl
api change to allow process killing as a service (16.97 KB, patch)
2009-07-01 11:43 UTC, Milos Kleint
Details | Diff
patch JG01 & JG02 (2.57 KB, text/plain)
2009-07-09 10:16 UTC, Petr Hejl

Note You need to log in before you can comment on or make changes to this bug.
Description bkwillis 2008-06-24 16:37:45 UTC
Groovy and Grails Plugin Version: 1.3 Source: NetBeans IDE Dev (Build 200806230002)

When clicking the Stop button in the NetBeans output window of a running grails application, the java process is not
terminated.  Rerunning the app from NetBeans (or running "grails run-app" in a terminal window) results in a long list
of " Address already in use: bind" errors.  Using the Windows task manager to terminate java
processes from previously running grails apps corrects the problem.  This problem has occurred on both Windows XP and
Vista PC's.
Comment 1 schmidtm 2008-06-25 15:05:30 UTC

you gotta have "taskkill.exe" in your path. Could you verify this? It's *not* shipped with the Home edition of MS Windows XP.


Matthias Schmidt
Comment 2 bkwillis 2008-06-26 12:50:21 UTC
taskkill.exe is in the c:/windows/system32 directory, which is in my path.  Typing "taskkill /?" at a command prompt 
returns the taskkill help.

Comment 3 Petr Hejl 2008-07-11 15:58:50 UTC
This is known win problem - it is quite hard to guarantee process tree to be killed on windows (at least from java).
Attaching the patch that could fix this on the level of extexecution API. The patch is using winp library:
Comment 4 Petr Hejl 2008-07-11 16:00:33 UTC
Created attachment 64346 [details]
the patch (using winp)
Comment 5 Petr Hejl 2008-07-11 21:11:51 UTC
I've investigated some other methods to kill process tree on windows. AFAIK there is no reasonably reliable solution
other than usage of native code. Other options are:

taskkill, kill, pskill - only on some versions and editions of windows, needs to know pid - native call to figure it out
jna - the native code is not just a simple call (could be really messy), unclear which jna.jar (or custom one) should be

Kohsuke's code seems pretty usable, I'm not sure about the MIT license and win64 compatibility.
Comment 6 Petr Hejl 2008-07-11 21:28:01 UTC
Jesse, just in case you had to solve this already... Any comments/preferred solution?
Thanks for any suggestions.
Comment 7 Petr Hejl 2008-07-14 17:07:12 UTC
Groovy issue was workarounded in 66184693d711.

However this is a generic issue with destroying the process tree on windows and is related to extexecution. Changing
Comment 8 Jesse Glick 2008-07-14 20:51:34 UTC
General solution to what? If you are referring to Ant builds, these just call Process.destroy() if you click Stop; it is
up to the process being run to kill any children it might have spawned. (In the case of NetBeans IDE or platform apps,
this is handled on Unix system using some Bourne shell magic, and on Windows probably not at all.)
Comment 9 Petr Hejl 2008-07-16 19:50:35 UTC
I've meant any process run from the ide which can be terminated by the user. While destroying the process on *nix works
fine including the children it does not work on windows.

This is trouble when invoking any batch script (grails.bat for example). We could do some magic to control this
particular case and kill spawned children, but that would need tracking changes in such script. When we will provide
some "External Tool" support it is impossible to do so. Users will then comply about active processes in the system
which should not exist anymore.

So I'm trying to find out proper solution for killing (destroying) the process including its children on windows.
Kohsuke (and others as well) had to solve exactly the same problem in hudson. He end up with dll - I do not have any
better solution. So what I'm proposing is to put this solution to NetBeans (extexecution). is related to the same problem.
Comment 10 Jesse Glick 2008-07-16 20:09:01 UTC
"destroying the process on *nix works fine including the children" - this is not true, I think. Process.destroy() on
Unix just sends SIGTERM to the actual process, which may result in it being killed while children remain alive.

In the case of killing platform*/lib/nbexec launched from Ant for module development, we work around this problem by
having that script capture SIGTERM and kill the Java process too. (bin/netbeans exec's nbexec so its own process is
gone, but nbexec must remain running so it can implement AU restart.)

Ctrl-C from a shell actually traverses the transitive process group and kills them all; native code for Unix systems
could do the same for us. For Windows it is trickier because (as I understand it) there is not a standard API to get a
transitive subprocess graph except the Win2000+ "Job".

BTW I would recommend use of JNA rather than shipping *.dll/*.so. It is likely to be easier to maintain, as there are no
binary files to keep in source control (other than JNA itself) and you don't need a special IDE or build tool to patch
the native code, just a Java editor. We include JNA in the platform cluster already.

At least on Unix, getting the PID from a Process object is easy using reflection (in the Sun JRE impl at least).
Comment 11 Petr Hejl 2008-08-20 12:39:21 UTC
This is an enhancement. In groovy this is already solved.
Comment 12 Petr Hejl 2009-04-14 12:11:38 UTC
This is still causing problems. Could we incorporate winp library (now 64 bit is available) and take the best effort

I think this problem will become more severe as we are adopting more and more external tools (grails, maven, php...).
Comment 13 Milos Kleint 2009-07-01 11:43:58 UTC
Created attachment 84235 [details]
api change to allow process killing as a service
Comment 14 Milos Kleint 2009-07-01 13:36:23 UTC
the api (please review)

the provider module

maven execution using the api

Comment 15 Petr Hejl 2009-07-01 15:14:08 UTC
I'm going to move DestroyUtils to org.netbeans.api.extexecution.ExternalProcessSupport and I'll remove the String
constant which is actually not used anywhere.
Comment 16 Milos Kleint 2009-07-01 16:46:51 UTC
no objections, however please note that the constant is used in the maven module already.
Comment 17 Petr Hejl 2009-07-01 21:22:48 UTC
desc16 fixed:
Comment 18 Quality Engineering 2009-07-03 05:58:31 UTC
Integrated into 'main-golden', will be available in build *200907030200* on (upload may still be in progress)
User: Milos Kleint <>
Log: #138116 add api to allow pluggable means of destroying an external process.
Comment 19 Jesse Glick 2009-07-09 00:43:09 UTC
[JG01] Javadoc for 'env' param to destroy(...) should be made clearer, especially why a Map is passed which might have
multiple keys (what would the behavior then be?).

[JG02] It is not acceptable for WrapperProcess and MavenCommandLineExecutor to implicitly share a constant. If this
value is magical then it needs to be exposed in the API.
Comment 20 Petr Hejl 2009-07-09 10:15:16 UTC
Re JG01: Updated.
Re JG02: It is not a magic value. Maven and extexecution are using different variables now.

Attaching patch.
Comment 21 Petr Hejl 2009-07-09 10:16:13 UTC
Created attachment 84530 [details]
patch JG01 & JG02
Comment 22 Petr Hejl 2009-07-09 19:48:53 UTC
If there are no more objections, I'll apply the patch and close the issue tomorrow.
Comment 23 Petr Hejl 2009-07-10 12:04:03 UTC
Fixed in web-main 5e107d3fef7a.

Also fixes arch.xml & apichanges.xml.
Comment 24 Quality Engineering 2009-07-11 06:26:10 UTC
Integrated into 'main-golden', will be available in build *200907110200* on (upload may still be in progress)
Log: #138116 Stopping a running app doesn't stop the child process