8022206: Intermittent test failures in java/lang/ProcessBuilder/Basic.java

[Stuart Marks]

On 11/19/13 1:41 PM, Alan Bateman wrote:
> On 19/11/2013 20:14, Martin Buchholz wrote:
>> In jsr166 tests we have mostly switched to 10 second timeouts to mean "forever".
>> But in ProcessBuilder tests we are starting up new java processes with their
>> well-known startup problems, so using a much larger value of "forever" seems
>> reasonable.  I vote for 1 minute.  You can write
>>
>> waitFor(1, TimeUnit.MINUTES);
>>
> I agree that a timeout on that order might be needed when starting process.
> However I think this one is just starting a thread that exercises the new
> waitFor method.

I'll share a discussion we had before I pushed my "fix" yesterday that raised a 
timeout from 30 to 60 seconds.

http://hg.openjdk.java.net/jdk8/tl/jdk/rev/19d2e9649138

Some of the test machines in our test farm can be startlingly, even absurdly 
slow. In this case part of the test involved having a parent process fork a 
child process, and the child turns around and connects back to the parent. 
There's a 30 second timeout for this. It should never timeout, right? But it did 
in our testing environment.

One clue is that on my laptop, this test (including framework setup and 
teardown) took about 8 seconds to run. The test log of the failure showed that 
the test took 2 MINUTES AND 49 SECONDS to run.

(This was on 32-bit Windows, of course.)

I can only guess at what causes the machines to run so slowly (virus scanning? 
other VMs running on the same host?) but sometimes they can be so slow that the 
unbelievable happens.

s'marks