Igor, Ioi,
I have read Ioi's mail and the supposed bug fix.
While the fix may hide the problem, the root cause is still that tests
are not providing accurate @build directives, and are relying on
implicit compilation to compile the files. This is not the way that
jtreg is intended to be used, and the fix merely helps hide the problem,
albeit in a relatively elegant way.
-- Jon
On 05/31/2017 07:18 AM, Igor Ignatyev wrote:
Hi Alan,
we believe it's a jtreg bug. we have seen similar intermittent failures in
hotspot testing[1], Ioi(cc'ed) did a really great job analyzing the root
cause[2], in to words jtreg puts a part of testlibrary to one path and another
part to a different path. [3] is his suggested fix for jtreg.
-- Igor
[1] https://bugs.openjdk.java.net/browse/CODETOOLS-7901986
[2]
https://bugs.openjdk.java.net/secure/attachment/70197/jtreg_random_class_not_found.txt
[3] http://cr.openjdk.java.net/~iklam/jtreg/7901986_split_library/
On May 31, 2017, at 1:38 AM, Alan Bateman <[email protected]> wrote:
On 31/05/2017 09:05, Felix Yang wrote:
Hi Alan
even with explicit compilation, I also observed failures. I'm curious what
is the best practice here. IMO, there could be a potential jtreg bug.
One of the tests listed in JDK-8181299 is
java/net/URLConnection/6212146/TestDriver.java. In jdk10/jdk10 the test
description has:
@build jdk.test.lib.JDKToolFinder jdk.test.lib.process.ProcessTools Test
but the test fails intermittently with:
java.lang.NoClassDefFoundError: jdk/test/lib/process/StreamPumper
at jdk.test.lib.process.ProcessTools.getOutput(ProcessTools.java:85)
at jdk.test.lib.process.OutputAnalyzer.<init>(OutputAnalyzer.java:47)
at jdk.test.lib.process.ProcessTools.executeProcess(ProcessTools.java:397)
at jdk.test.lib.process.ProcessTools.executeProcess(ProcessTools.java:425)
at jdk.test.lib.process.ProcessTools.executeCommand(ProcessTools.java:475)
at TestDriver.main(TestDriver.java:61)
I assume changing the @build to jdk.test.lib.process.* will fix this, assuming
all the classes needed for ProcessTools are in this package.
As to why it's intermittent then I think it's a side effect of test library
classes being compiled by one test and then re-used by a test that runs
sometime later in the same VM. Combine that with implicit compilation, varied
@build usages, and concurrently should explain why it's intermittent. I see
you've cc'ed Jon Gibbons and he is the best person to comment on this. Now
seems a good time to get to the bottom of these issues, esp. with Igor changing
lots of tests to drop the explicit compilation of test library classes.
-Alan
