[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    Re: RFR 8059034: ProcessTools.startProcess() might leak processes
From:       roger riggs <roger.riggs () oracle ! com>
Date:       2014-09-25 13:39:02
Message-ID: 54241AF6.3040907 () oracle ! com
[Download RAW message or body]

Hi,

The spec for destroyForcibly goes on to say that ProcessBuilder 
implements destroyForcibly correctly.

" Invoking this method on Process objects returned by 
ProcessBuilder.start() and Runtime.exec(java.lang.String) will forcibly 
terminate the process. "

Roger

On 9/25/2014 6:24 AM, Jaroslav Bachorik wrote:
> On 09/25/2014 12:13 PM, Staffan Larsen wrote:
>> I wonder if the p.waitFor() is needed? What if the process launching 
>> expired with a timeout and now we are still waiting for the process 
>> to end - wouldn’t that kind of defeat the timeout? In any case, the 
>> destroyForcibly() should end the process whether we wait for it or not.
>
> It would be wonderful but the javadoc states that the result of 
> destroyForcibly() call depends on the implementation and may actually 
> not force close the process and one should use waitFor() to make sure 
> that the process has in fact died.
>
> I wonder whether JTReg kills the process tree on timeout - in case it 
> does using waitFor() would guarantee that there would be no zombies 
> left. Without using waitFor() and semantics of destroyForcibly() there 
> might be situations when non-functional stuck processes are left 
> behind (not sure how probable, however).
>
> -JB-
>
>>
>> /Staffan
>>
>>
>> On 25 sep 2014, at 11:54, Jaroslav Bachorik 
>> <jaroslav.bachorik@oracle.com> wrote:
>>
>>> Please, review the following change to the JDK test library class
>>>
>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8059034
>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8059034/webrev.00
>>>
>>> Currently, the ProcessTools.startProcess() might leave a dangling 
>>> process behind when a timeout or interrupt happens. The solution is 
>>> to try and forcibly terminate the forked process when this happens.
>>>
>>> Thanks,
>>>
>>> -JB-
>>
>

[prev in list] [next in list] [prev in thread] [next in thread]