On 05/31/2017 01:38 AM, Alan Bateman 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 Igorchanging lots of tests to drop the
explicit compilation of test library classes.
-Alan
That's a Big Red Flag with a Titanic-sized fog-horn warning of the danger.
jtreg is no different from make. If you want concurrency, you *must*
provide accurate dependency information. As a general rule, each test
should accurately define what library classes need to be built in order
for it to be executed reliably and correctly in a multi-threaded
environment.
The one exception/clarification to make to that rule is that as a
general rule, you can/should replace @compile with @build. @compile
always performs a compilation, @build only performs the compilation if
the .class file is out of date.
I'll echo Alan's comment, which hit the nail on the head:
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.
If you want a tip for seeing if you have the correct set o0f @build
directives for a test ... use jtreg to build/run just that one test by
itself in a *clean*/empty work directory. Look at the classes that
were compiled. Were any of the generated classes compiled implicitly,
i.e. not mentioned in @build directives? If so, add suitable @build
directives.
-- Jon
