Process.destroy() on Win32

[Joshua Jones]

Running on Win2k. I have something like this:

AntThread.java
==============
Process p;
try {
p = Runtime.getRuntime().exec(commandLine);
...
p.waitFor();
}
....
catch (InterruptedException e) {
p.destroy();
p = null;
}
finally {
cleanup();
}
==============

Another thread calls AntThread's interrupt() method, and I get to the
InterruptedException catch block. For some reason, however, this
process (an ant build process, which itself uses java) does not end.
I continue getting output from it, and only if I kill the process
manually through the task manager will it stop.

I can't get the PID from Java or anywhere else, which would be kludgy
anyway. Does anyone know why the destroy() method is not destroying,
or better yet, a solution?

 

[Paul Lutus]

Running on Win2k. I have something like this:

AntThread.java
==============
Process p;
try {
p = Runtime.getRuntime().exec(commandLine);
...
p.waitFor();
}
...
catch (InterruptedException e) {
p.destroy();
p = null;
}
finally {
cleanup();
}
==============

Another thread calls AntThread's interrupt() method, and I get to the
InterruptedException catch block. For some reason, however, this
process (an ant build process, which itself uses java) does not end.
I continue getting output from it, and only if I kill the process
manually through the task manager will it stop.

I can't get the PID from Java or anywhere else, which would be kludgy
anyway. Does anyone know why the destroy() method is not destroying,
or better yet, a solution?

The problem appears to be p.waitfor(), which locks the thread. In this
arrangement, when you interrupt the thread, the InterruptedException may
not be executed.

This is just a guess.

 

[Matt Humphrey]

Running on Win2k. I have something like this:

AntThread.java
==============
Process p;
try {
p = Runtime.getRuntime().exec(commandLine);
...
p.waitFor();
}
...
catch (InterruptedException e) {
p.destroy();
p = null;
}
finally {
cleanup();
}
==============

Another thread calls AntThread's interrupt() method, and I get to the
InterruptedException catch block. For some reason, however, this
process (an ant build process, which itself uses java) does not end.
I continue getting output from it, and only if I kill the process
manually through the task manager will it stop.

I can't get the PID from Java or anywhere else, which would be kludgy
anyway. Does anyone know why the destroy() method is not destroying,
or better yet, a solution?

Does your command line program generate output? If it produces output on
stdout or stderr and you do not actually read that output, the process will
block waiting for you to read it. The output is not automatically consumed,
but fills up a buffer and when it gets full (1K or so) the process will
block. The standard solution is to initiate two threads that consume the
process's output--you can find it in a google search.

Cheers,
Matt Humphrey (e-mail address removed) http://www.iviz.com/

 

[Joshua Jones]

Does your command line program generate output? If it produces output on
stdout or stderr and you do not actually read that output, the process will
block waiting for you to read it. The output is not automatically consumed,
but fills up a buffer and when it gets full (1K or so) the process will
block. The standard solution is to initiate two threads that consume the
process's output--you can find it in a google search.

Cheers,
Matt Humphrey (e-mail address removed) http://www.iviz.com/

Actually Matt, I'm already doing that: one thread for stdout, one
thread for stderr, both outputting to a JTextArea (sort of a status
console).

This almost reminds me of using unix, where a "kill" won't work, so a
"kill -9" must be issued. The tool I'm working on is a builder for a
large program which spawns an external ant process. It goes something
like this: main thread spawns AntThread, which spawns: ant Process,
and the two output capture threads. It just seems like p.destroy()
has no effect whatsoever. I keep getting output in my JTextArea from
the ant process.

 

[Joshua Jones]

The problem appears to be p.waitfor(), which locks the thread. In this
arrangement, when you interrupt the thread, the InterruptedException may
not be executed.

This is just a guess.

Paul, thanks for your recommendation. However, the catch block is
being reached successfully (see the original message).

 

[Matt Humphrey]

"Matt Humphrey" <[email protected]> wrote in message

Actually Matt, I'm already doing that: one thread for stdout, one
thread for stderr, both outputting to a JTextArea (sort of a status
console).

This almost reminds me of using unix, where a "kill" won't work, so a
"kill -9" must be issued. The tool I'm working on is a builder for a
large program which spawns an external ant process. It goes something
like this: main thread spawns AntThread, which spawns: ant Process,
and the two output capture threads. It just seems like p.destroy()
has no effect whatsoever. I keep getting output in my JTextArea from
the ant process.

Well, it's good that you're doing the dual reading as it's one less problem.
Other people have had similar problems with destroy, although theirs seems
to more that process.destroy () is killing the top-level shell and not the
main processes sub processes. If you're on W2K, are you using start? Could
your process be spawning processes of its own (e.g. JVM that you mentioned)
such that destroy only kills the top process and not the children?

http://forum.java.sun.com/thread.jsp?forum=31&thread=283771&message=1110436

http://forum.java.sun.com/thread.jsp?thread=458229&forum=31&message=2095297

This one is interesting because the last entry shows someone that created a
test program that just dumps output and when run under windows it can't be
stopped. (The bulk of the thread here is not useful for your problem.)
http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=27&t=
000708

Can't kill processes on Linux--bug report
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4399763

This bug report shows (in the comments at the bottom) that Ant will not
necessarily kill all its subprocesses when it itself is killed with destroy.
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4485742

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4770092

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4212450


There's another article that shows that subprocess / external process
behavior is not well specified by the JLS. I can't think of anything
else--you may need to craft a different kind of workaround.

Good luck,
Matt Humphrey (e-mail address removed) http://www.iviz.com/

 

[Paul Lutus]

Paul, thanks for your recommendation. However, the catch block is
being reached successfully (see the original message).

Yes, sorry, I missed that. Then try not setting the Process reference to
null after the destroy call. Just abandon it -- let it go out of scope.

It's just possible that the native-code equivalent signal for "destroy" is
simply being ignored by the process.

 

[Rene]

This almost reminds me of using unix, where a "kill" won't work, so a
"kill -9" must be issued. The tool I'm working on is a builder for a

This is a bit a broad statement. kill on unix works fine, however you need
to understand what it does. It just signals the program that it should
terminate and gives the program a chance to do proper cleanup. If the
program at this point however is locked/crashed/otherwise fucked, it
probably won't exit at this stage. kill -9 however simply removes the
process from the system and frees all memory and filedescriptor ressources
it used. The program being killed has no way to intercept or delay a kill
-9. kill -9's can hang however, for example when the process to be killed
is doing a priviledged uninterruptable io operation, because that is being
done in kernel space and understandably, you're not supposed to kill the
kernel.

CU

René

 

[Joshua Jones]

Well, it's good that you're doing the dual reading as it's one less problem.
Other people have had similar problems with destroy, although theirs seems
to more that process.destroy () is killing the top-level shell and not the
main processes sub processes. If you're on W2K, are you using start? Could
your process be spawning processes of its own (e.g. JVM that you mentioned)
such that destroy only kills the top process and not the children?

http://forum.java.sun.com/thread.jsp?forum=31&thread=283771&message=1110436

http://forum.java.sun.com/thread.jsp?thread=458229&forum=31&message=2095297

This one is interesting because the last entry shows someone that created a
test program that just dumps output and when run under windows it can't be
stopped. (The bulk of the thread here is not useful for your problem.)
http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=27&t=
000708

Can't kill processes on Linux--bug report
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4399763

This bug report shows (in the comments at the bottom) that Ant will not
necessarily kill all its subprocesses when it itself is killed with destroy.
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4485742

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4770092

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4212450


There's another article that shows that subprocess / external process
behavior is not well specified by the JLS. I can't think of anything
else--you may need to craft a different kind of workaround.

Thanks for all the helpful articles Matt... I'll get on these right away.