RFR 8062070: com/sun/jdi/DoubleAgentTest.java.DoubleAgentTest fails intermittently after 8056143
Jaroslav Bachorik
jaroslav.bachorik at oracle.com
Mon Oct 27 18:00:27 UTC 2014
On 10/26/2014 11:53 PM, David Holmes wrote:
> On 25/10/2014 3:06 AM, Jaroslav Bachorik wrote:
>> Please, review this change to the test library.
>>
>> Issue : https://bugs.openjdk.java.net/browse/JDK-8062070
>> Webrev: http://cr.openjdk.java.net/~jbachorik/8062070/webrev.00
>>
>> The test started failing after the process.destroyForcibly() was added
>> to ProcessTools.executeProcess() to make sure there were no orphaned
>> processes once the test was finished. The destruction call was placed to
>> the finally block and was called for running or terminated processes
>> indiscriminately.
>>
>> It turns out that Process.get*Stream() methods will get confused when
>> calling Process.destroy/Forcibly/() on an already exited process - the
>> streams will get closed and any attempt to read or write to them will
>> end with a SocketException.
>>
>> The failure is timing related - when the stream manages to buffer data
>> before destroying the process from another thread the test passes.
>> Otherwise it just fails.
>>
>> The solution is to forcibly close the external process (started by
>> ProcessTools.executeProcess()) only in cases when eg. Process.waitFor()
>> throws an exception - moving it from the finally block to the catch
>> block.
>
> I can't help but think we are simply shifting the failure window around.
> But the proof of this is in the testing.
I don't know whether we can do any better while keeping the
post-condition of having the process exited before leaving this method.
But with this change we would hit this problem in cases when the test
would be already failing anyway.
I ran JPRT on all the available platforms and the test didn't fail once.
Thanks for the reviews.
-JB-
>
> Reviewed.
>
> David
>
>
>> Thanks,
>>
>> -JB-
More information about the serviceability-dev
mailing list