Bug ID: JDK-8148000 test class files are being overwritten

we don't see truncated errors/no class found and similar things after removing '/../..' from @library (JDK-8148012/JDK-8140189). in case this happens again, please file a new bug.
01-03-2016
My observation is incorrect since it was reuing the same workdir. However - the error received are the same - so might there be a race in the concurrent case? (Two different tests running the Whitebox.regersterNatives at the same time.)
10-02-2016
I ran this on three terminals at the same time: repeat 3 /home/neliasso/tools/jtreg/bin/jtreg -jdk /home/neliasso/repos/compiler_control/build/linux-x86_64-normal-server-fastdebug/images/jdk -vmoptions:"-XX:+PrintCompilation -XX:CICompilerCount=4" hotspot/test/compiler/compilercontrol/TestCompilerDirectivesCompatibilityBase.java hotspot/test/compiler/compilercontrol/TestCompilerDirectivesCompatibilityCommandOn.java hotspot/test/compiler/compilercontrol/TestCompilerDirectivesCompatibilityCommandOff.java hotspot/test/compiler/compilercontrol/TestCompilerDirectivesCompatibilityFlag.java hotspot/test/compiler/whitebox/EnqueueMethodForCompilationTest.java hotspot/test/compiler/whitebox/MakeMethodNotCompilableTest.java hotspot/test/compiler/whitebox/ClearMethodStateTest.java And ended up with variations on this: Test results: passed: 7 Report written to /home/neliasso/repos/compiler_control/JTreport/html/report.html Results written to /home/neliasso/repos/compiler_control/JTwork Test results: passed: 4; failed: 3 Report written to /home/neliasso/repos/compiler_control/JTreport/html/report.html Results written to /home/neliasso/repos/compiler_control/JTwork Error: Some tests failed or other problems occurred. Test results: passed: 7 Report written to /home/neliasso/repos/compiler_control/JTreport/html/report.html Results written to /home/neliasso/repos/compiler_control/JTwork Failures were Truncated class file and Unsatisfied link error on register natives. java.lang.UnsatisfiedLinkError: sun.hotspot.WhiteBox.registerNatives()V at sun.hotspot.WhiteBox.registerNatives(Native Method) at sun.hotspot.WhiteBox.<clinit>(WhiteBox.java:68) at compiler.whitebox.CompilerWhiteBoxTest.<clinit>(CompilerWhiteBoxTest.java:54) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:288) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:86) at java.lang.Thread.run(Thread.java:804) STATUS:Failed.`main' threw exception: java.lang.UnsatisfiedLinkError: sun.hotspot.WhiteBox.registerNatives() ---------System.err:(11/670)---------- java.lang.BootstrapMethodError: java.lang.ClassFormatError: Truncated class file at sun.hotspot.WhiteBox.<init>(WhiteBox.java:391) at sun.hotspot.WhiteBox.<clinit>(WhiteBox.java:48) at compiler.whitebox.CompilerWhiteBoxTest.<clinit>(CompilerWhiteBoxTest.java:54) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:288) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:86) at java.lang.Thread.run(Thread.java:804) Caused by: java.lang.ClassFormatError: Truncated class file
09-02-2016
I tried to reproduce this again with compilercontrol tests. They haven't failed with -conc set to 10. I'm going to reproduce it more to make a simple reproducer. This could require some time to do this.
02-02-2016
OK, but to be clear: that means the ball is in your court for now. I've investigated, and for me, it seems like jtreg is generating correct paths, and so for me, the problem is currently "No Reproducible."
25-01-2016
Jon, that's the problem -- we aren't able to reliable reproduce that behavior. I asked Pavel to provide you w/ info what tests and in what circumstances fail more frequently.
25-01-2016
Update: I reran the compiler tests on a clean work directory. Same results. No problems.
25-01-2016
I definitely need details on a specific case. I tried running all the hotspot/test/compiler tests, with the latest jtreg, with -agentvm and with -conc:6. jtreg -jdk:build/linux-x86_64-normal-server-release/images/jdk -w build/jtreg/hswork -r build/jtreg/hsreport -v1 -conc:6 -agentvm hotspot/test/compiler Results: Test results: passed: 680; failed: 1; error: 28 Report written to /w/jjg/work/dev+closed/build/jtreg/hsreport/html/report.html Results written to /w/jjg/work/dev+closed/build/jtreg/hswork Error: Some tests failed or other problems occurred. All 28 Error results were of the form: Error. effective library path is outside the test suite: ../../test/lib The 1 Failure was: compiler/floatingpoint/Test15FloatJNIArgs.java Failed. Execution failed: `main' threw exception: java.lang.UnsatisfiedLinkError: Test15FloatJNIArgs.add15floats(FFFFFFFFFFFFFFF)F which (because of the JNI) looks like it was because of my not providing any native code libraries. Furthermore, according to new details added into .jtr files, there are no indications that jtreg is computing any paths incorrectly. For example, look at the following line of grep output: build/jtreg/hswork/compiler/jsr292/ConcurrentClassLoadingTest.jtr: class directory: /w/jjg/work/dev+closed/build/jtreg/hswork/classes/5/testlibrary In all cases, "hswork/classes/" is followed by a digit that is used to keep separate the class files from different concurrently executing tests. So, summarize: To investigate this further, I need a relatively simple reproducible test case, or, it may be enough to provide a .jtr file from the latest version of jtreg. A reproducible test case means the name of a test or group of tests, that I can run by jtreg from the command line, to demonstrate the error, either reliably, or at least most of the time. If you post a .jtr file, make sure it has a block of text like this, in the output: Library /testlibrary; kind: packages source directory: /w/jjg/work/dev+closed/hotspot/test/testlibrary class directory: /w/jjg/work/dev+closed/build/jtreg/hswork/classes/2/testlibrary Library /test/lib; kind: packages source directory: /w/jjg/work/dev+closed/test/lib class directory: /w/jjg/work/dev+closed/build/jtreg/hswork/classes/2/test/lib Library /compiler/testlibrary; kind: packages source directory: /w/jjg/work/dev+closed/hotspot/test/compiler/testlibrary class directory: /w/jjg/work/dev+closed/build/jtreg/hswork/classes/2/compiler/testlibrary Library ../share; kind: packages source directory: /w/jjg/work/dev+closed/hotspot/test/compiler/compilercontrol/share class directory: /w/jjg/work/dev+closed/build/jtreg/hswork/classes/2/compiler/compilercontrol/share Library /; kind: packages source directory: /w/jjg/work/dev+closed/hotspot/test class directory: /w/jjg/work/dev+closed/build/jtreg/hswork/classes/2
25-01-2016
Can you give me an example of how you would execute one of the tests that demonstrates a failure? Is there a test that doesn't require much in the way of special options for jtreg (e.g. like -nativepath) ? And, can you specify explicitly, a specific test or group of tests to investigate, rather than just referring back to older bug reports than may or may not be up to date. For example, I just tried the compilercontrol tests and all failed with either the new ../ error, or they ran sun successfully. I'm looking to reduce this down to a simple test case, that I can run with custom versions of jtreg.
25-01-2016
[~jjg], as I mentioned before the tests which fail or are running simultaneously don't have '@library /..', and as we figured out jtreg makes incorrect paths for libraries. so it looks like a bug in jtreg to me.
25-01-2016
There is no point reassigning this back to CODETOOLS, since there is nothing more I can do at this stage. At least part of the problem was the use of library paths that point outside the test suite. jtreg now explicitly detects and forbids that. There is a replacement mechanism already in place, based on the use of external.lib.dirs. As I see it, the next step in this investigation is to update the tests that have been using these bad relative paths. At that point, the VM SQE team should determine whether this problem of tests overwriting each other still exists. If fixing the bad relative paths fixes the overwriting issue, then we're done, and this issue can be closed. If this issue still persists, when the tests have been updated to use valid @library paths, then we will have to look at this again to find additional contributing factors. But, in such an investigation, I would continue to focus primarily on the tests themselves, and the library code that is used; this problem of tests overwriting each other has never appeared before, in any other context.
25-01-2016
[~jjg]: > Re: Igor's recent comment about jtreg making paths from external.lib.roots: > I will investigate. should we move this bug back to CODETOOLS project? assign it to you?
25-01-2016
Yes, the library path should be generally normalized, in the URI.normalize sense, such that the resulting path relative to the base classes directory should not begin with .. Thus, in your example, Test{A,B,C,D} should not be allowed to have '@library ../../../../share' ----- Separately, note that in the upcoming new version of jtreg, there will be a listing in the .jtr file of all the libraries used by the test, their type, and their source and class locations.
22-01-2016
I've filed CODETOOLS-7901585 for '/.. in @library' topic.
22-01-2016
I'm sorry I meant 'dot-dot', so prohibit slash-dot-dot, but still allow dot-dot. in some cases we have testlibrary specific for some group of tests located near them, smth like - /foo/share/Lib.java - /foo/bar/TestA.java - /foo/bar/TestB.java - /foo/baz/TestC.java - /foo/baz/TestD.java Test{A,B,C,D} have '@library ../share'
22-01-2016
Re: Igor's recent comment about jtreg making paths from external.lib.roots: I will investigate.
22-01-2016
jtreg normalizes the files, so any simple leading ./ will have disappeared by the time the check is made.
22-01-2016
I've filed JDK-8148012 to clean it up. And I think it definitely makes sense to prohibit slash-dot in @library, although just dot can be acceptable.
22-01-2016
Re: [~jjg], according to the log, the test fails in 3rd build section, looking at test description, we see that it means that none of test class has been executed. Given the fact that different concurrent runs use different directories, I don't see how it can be an issue w/ tests. Yes and no, and maybe there's enough issues here to go around. I still don't accept there's any way that javac would write the contents of a system class file (like java.io.PrintStream) into the contents of another class. That has be be a copy happening somewhere. But your point about separate directories is well taken, and indicates a potential issue. Look at that command you gave: here's an extract, reformatted for easier reading: 42072 com.sun.tools.javac.Main -d C:\Users\aurora\sandbox\results\workDir\test\lib\share\classes // ******* SOMETHING STRANGE HERE, we lost \classes\1 after workDir -classpath C:\Users\aurora\CommonData\JTREG_HOME\lib\javatest.jar; // OK C:\Users\aurora\CommonData\JTREG_HOME\lib\jtreg.jar; // OK C:\Users\aurora\sandbox\results\workDir\classes\1\serviceability\dcmd\gc; // contains workDir\classes\1 ... OK C:\Users\aurora\CommonData\TESTBASE\hotspot\test\serviceability\dcmd\gc; // looks like asource directory, OK C:\Users\aurora\sandbox\results\workDir\test\lib\share\classes; // ******* SOMETHING STRANGE HERE, we lost \classes\1 after workDir C:\Users\aurora\sandbox\results\workDir\classes\1\testlibrary; // contains workDir\classes\1 ... OK C:\Users\aurora\CommonData\JTREG_HOME\lib\testng.jar // OK And, although I've been looking at other tests, I see that this is not uncommon: * @library /../../test/lib We've been here before, CODETOOLS-7901527, and addressed this problem already. dot-dotting out of the test directory is not good, and there's a feature in place that tests should be using instead. It's probably no coincidence that there are two .. and we've lost two components in the corresponding entry in the classpath. Perhaps in the upcoming b13 we should flat out prohibit use of /.. in @library declarations. --------------- Note, while I suspect the use of @library /../../test/lib (or similar) is a contributing factor in the problems here, I accept it doesn't explain the overwriting we're apparently seeing, but we have made one step towards explaining the lack of isolation between tests executing concurrently.
22-01-2016
See JDK-8140189. I had fixed all occurrences of /../../test/lib. Looks like a bunch more crept in. "external.lib.roots = ../../" was added for that fix.
22-01-2016
Jon, there is no '@library /../../' in any of serviceability/dcmd/gc/ tests. BUT 'test\lib\share\classes' came from '@library /test/lib/share/classes' and this '/test/lib' isn't a /test/lib from test-root, it's /test/lib/ from 'external.lib.roots' (external.lib.roots = ../../). so it looks like we have a problem w/ making pathes for libraries from 'external.lib.roots' in case of concurrent execution. what do you think?
22-01-2016
FYI: occurrences of @library /.. in hotspot/test: $ grep -r ' @library.* /\.\.' hotspot/test hotspot/test/gc/g1/TestPLABOutput.java: * @library /testlibrary /../../test/lib hotspot/test/compiler/types/TestMeetIncompatibleInterfaceArrays.java: * @library /testlibrary /../../test/lib hotspot/test/compiler/intrinsics/IntrinsicDisabledTest.java: * @library /testlibrary /../../test/lib hotspot/test/compiler/intrinsics/montgomerymultiply/MontgomeryMultiplyTest.java: * @library /testlibrary /../../test/lib hotspot/test/compiler/stable/TestStableMemoryBarrier.java: * @library /testlibrary /../../test/lib hotspot/test/compiler/compilercontrol/commands/PrintTest.java: * @library /testlibrary /../../test/lib /compiler/testlibrary ../share / hotspot/test/compiler/compilercontrol/commands/CompileOnlyTest.java: * @library /testlibrary /../../test/lib /compiler/testlibrary ../share / hotspot/test/compiler/compilercontrol/commands/ExcludeTest.java: * @library /testlibrary /../../test/lib /compiler/testlibrary ../share / hotspot/test/compiler/compilercontrol/commands/LogTest.java: * @library /testlibrary /../../test/lib /compiler/testlibrary ../share / hotspot/test/compiler/compilercontrol/commandfile/PrintTest.java: * @library /testlibrary /../../test/lib /compiler/testlibrary ../share / hotspot/test/compiler/compilercontrol/commandfile/CompileOnlyTest.java: * @library /testlibrary /../../test/lib /compiler/testlibrary ../share / hotspot/test/compiler/compilercontrol/commandfile/ExcludeTest.java: * @library /testlibrary /../../test/lib /compiler/testlibrary ../share / hotspot/test/compiler/compilercontrol/commandfile/LogTest.java: * @library /testlibrary /../../test/lib /compiler/testlibrary ../share / hotspot/test/compiler/compilercontrol/TestCompilerDirectivesCompatibilityCommandOff.java: * @library /testlibrary /../../test/lib hotspot/test/compiler/compilercontrol/directives/PrintTest.java: * @library /testlibrary /../../test/lib /compiler/testlibrary ../share / hotspot/test/compiler/compilercontrol/directives/CompileOnlyTest.java: * @library /testlibrary /../../test/lib /compiler/testlibrary ../share / hotspot/test/compiler/compilercontrol/directives/ExcludeTest.java: * @library /testlibrary /../../test/lib /compiler/testlibrary ../share / hotspot/test/compiler/compilercontrol/directives/LogTest.java: * @library /testlibrary /../../test/lib /compiler/testlibrary ../share / hotspot/test/compiler/compilercontrol/TestCompilerDirectivesCompatibilityCommandOn.java: * @library /testlibrary /../../test/lib hotspot/test/compiler/compilercontrol/TestCompilerDirectivesCompatibilityBase.java: * @library /testlibrary /../../test/lib hotspot/test/compiler/compilercontrol/TestCompilerDirectivesCompatibilityFlag.java: * @library /testlibrary /../../test/lib hotspot/test/compiler/compilercontrol/mixed/RandomCommandsTest.java: * @library /testlibrary /../../test/lib /compiler/testlibrary ../share / hotspot/test/compiler/compilercontrol/mixed/RandomValidCommandsTest.java: * @library /testlibrary /../../test/lib /compiler/testlibrary ../share / hotspot/test/compiler/compilercontrol/jcmd/AddCompileOnlyTest.java: * @library /testlibrary /../../test/lib /compiler/testlibrary ../share / hotspot/test/compiler/compilercontrol/jcmd/AddExcludeTest.java: * @library /testlibrary /../../test/lib /compiler/testlibrary ../share / hotspot/test/compiler/compilercontrol/jcmd/AddLogTest.java: * @library /testlibrary /../../test/lib /compiler/testlibrary ../share / hotspot/test/compiler/compilercontrol/jcmd/AddAndRemoveTest.java: * @library /testlibrary /../../test/lib /compiler/testlibrary ../share / hotspot/test/compiler/compilercontrol/jcmd/AddPrintAssemblyTest.java: * @library /testlibrary /../../test/lib /compiler/testlibrary ../share / hotspot/test/compiler/cpuflags/TestAESIntrinsicsOnUnsupportedConfig.java: * @library /testlibrary /../../test/lib /compiler/whitebox hotspot/test/compiler/cpuflags/TestAESIntrinsicsOnSupportedConfig.java: * @library /testlibrary /../../test/lib /compiler/whitebox
22-01-2016
since jtreg was run w/ -conc:2, and in jtreg's output we have: 2015-10-22 03:29:44 [AG][72632] [Passed: serviceability/dcmd/gc/FinalizerInfoTest.java] 2015-10-22 03:29:53 [AG][72632] [FAILED: serviceability/dcmd/gc/HeapDumpTest.java] 2015-10-22 03:30:28 [AG][72632] [Passed: serviceability/dcmd/gc/HeapInfoTest.java] most probably that compilation wa from FinalizerInfoTest or HeapInfoTest. brief looking at their code shows that both of them don't run javac from test code, only via @build so to me it looks like this problem occurs when jtreg simultaneously compiles the same java file.
22-01-2016
looking at output of jps which was executed by jtreg observer after HeapDumpTest had failed, we see that there is another instance of javac compiling the same java file -- C:\Users\aurora\CommonData\TESTBASE\test\lib\share\classes\jdk\test\lib\hprof\HprofParser.java [2015-10-22 03:29:48] [c:\users\aurora\CommonData\JDK_DIR\bin\jps.exe, -mlv] ---------------------------------------- 9604 C:/users/aurora/CommonData/JTREG_HOME/lib/jtreg.jar -verbose:summary -testjdk:c:/users/aurora/CommonData/JDK_DIR -dir:c:/users/aurora/CommonData/TESTBASE/hotspot/test -w:C:/users/aurora/sandbox/results/workDir -r:C:/users/aurora/sandbox/results/report -retain:fail,error,hs_err* -a -javacoptions: -javaoption:-Xcomp -javaoption:-server -javaoption:-XX:MaxRAMFraction=8 -javaoption:-XX:+CreateCoredumpOnCrash -javaoption:-XX:+IgnoreUnrecognizedVMOptions -javaoption:-XX:-UseCompressedOops -javaoption:-XX:ReservedCodeCacheSize=256M -exclude:C:/users/aurora/sandbox/results/exclude.jtx -k:!jfr&!ignore -conc:2 -timeout:16 -nativepath:c:/users/aurora/CommonData/JTREG_NATIVEPATH/hotspot/jtreg/native -thd:c:/users/aurora/CommonData/JTREG_EFH_HOME/lib/jtregEFH.jar -th:jdk.test.jtreg.handler.GatherProcessInfoTimeoutHandler -od:c:/users/aurora/CommonData/JTREG_EFH_HOME/lib/jtregEFH.jar -o:jdk.test.jtreg.handler.GatherDiagnosticInfoObserver -othervm . -XX:+UseSerialGC -Xmx256M -Djavatest.script.jtrIfPassed=false -Dprogram=jtreg 42072 com.sun.tools.javac.Main -d C:\Users\aurora\sandbox\results\workDir\test\lib\share\classes -classpath C:\Users\aurora\CommonData\JTREG_HOME\lib\javatest.jar;C:\Users\aurora\CommonData\JTREG_HOME\lib\jtreg.jar;C:\Users\aurora\sandbox\results\workDir\classes\1\serviceability\dcmd\gc;C:\Users\aurora\CommonData\TESTBASE\hotspot\test\serviceability\dcmd\gc;C:\Users\aurora\sandbox\results\workDir\test\lib\share\classes;C:\Users\aurora\sandbox\results\workDir\classes\1\testlibrary;C:\Users\aurora\CommonData\JTREG_HOME\lib\testng.jar -sourcepath C:\Users\aurora\CommonData\TESTBASE\hotspot\test\serviceability\dcmd\gc;C:\Users\aurora\CommonData\TESTBASE\test\lib\share\classes;C:\Users\aurora\CommonData\TESTBASE\hotspot\test\testlibrary -XDignore.symbol.file=true C:\Users\aurora\CommonData\TESTBASE\test\lib\share\classes\jdk\test\lib\hprof\HprofParser.java -Dapplication.home=c:\users\aurora\CommonData\JDK_DIR -Xms8m -Dtest.src=C:\Users\aurora\CommonData\TESTBASE\hotspot\test\serviceability\dcmd\gc -Dtest.src.path=C:\Users\aurora\CommonData\TESTBASE\hotspot\test\serviceability\dcmd\gc;C:\Users\aurora\CommonData\TESTBASE\test\lib\share\classes;C:\Users\aurora\CommonData\TESTBASE\hotspot\test\testlibrary -Dtest.classes=C:\Users\aurora\sandbox\results\workDir\classes\1\serviceability\dcmd\gc -Dtest.class.path=C:\Users\aurora\sandbox\results\workDir\classes\1\serviceability\dcmd\gc;C:\Users\aurora\sandbox\results\workDir\test\lib\share\classes;C:\Users\aurora\sandbox\results\workDir\classes\1\testlibrary -Dtest.vm.opts= -Dtest.tool.vm.opts= -Dtest.compiler.opts= -Dtest.java.opts=-Xcomp -server -XX:MaxRAMFraction=8 -XX:+CreateCoredumpOnCrash -XX:+IgnoreUnrecognizedVMOptions -XX:-UseCompressedOops -XX:ReservedCodeCacheSize=256M -Dtest.jdk=c:\users\aurora\CommonData\JDK_DIR -Dcompile.jdk=c:\users\aurora\CommonData\JDK_DIR -Dtest.timeout.factor=16.0 -Dtest.nativepath=c: 73660 sun.tools.jps.Jps -mlv -Dapplication.home=c:\users\aurora\CommonData\JDK_DIR -Xms8m ---------------------------------------- [2015-10-22 03:29:50] exit code : 0 time : 2272295 ms ----------------------------------------
22-01-2016
[~jjg], according to the log, the test fails in 3rd build section, looking at test description, we see that it means that none of test class has been executed. Given the fact that different concurrent runs use different directories, I don't see how it can be an issue w/ tests. /* * @test * @summary Test of diagnostic command GC.heap_dump * @library /testlibrary * @library /test/lib/share/classes * @modules java.base/sun.misc * java.compiler * java.management * jdk.jvmstat/sun.jvmstat.monitor * @build jdk.test.lib.* * @build jdk.test.lib.dcmd.* * @build jdk.test.lib.hprof.* * @build jdk.test.lib.hprof.module.* * @build jdk.test.lib.hprof.parser.* * @build jdk.test.lib.hprof.utils.* * @run testng HeapDumpTest */
22-01-2016
The indications are very strong that this is a failure of code within the test suite, so I'm assigning it back to the component team. jtreg is a relatively simple client of javac, and there is no way that javac would write the contents of java.io.PrintStream into the classfile for jdk.test.lib.hprof.model.Snapshot. If it's not ClassFileInstaller, it has to be something else similar that is going on here. Reassigning to hotspot. Renamed: old summary: JTreg incorrectly builds tests with shared classes new summary: test class files are being overwritten
22-01-2016
serviceability/dcmd/gc/HeapDumpTest.java (http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/file/91be2fb6db87/test/serviceability/dcmd/gc/HeapDumpTest.java) doesn't have ClassFileInstaller or something similar, but has failed w/ bad class file: C:\\Users\\aurora\\CommonData\\TESTBASE\\test\\lib\\share\\classes\\jdk\\test\\lib\\hprof\\HprofParser.java:31: error: cannot access Snapshot import jdk.test.lib.hprof.model.Snapshot; ^ bad class file: C:\\Users\\aurora\\sandbox\\results\\workDir\\test\\lib\\share\\classes\\jdk\\test\\lib\\hprof\\model\\Snapshot.class class file contains wrong class: java.io.PrintStream Please remove or make sure it appears in the correct subdirectory of the classpath. 1 error result: Failed. Compilation failed: Compilation failed
22-01-2016
There's definitely an issue here, so I won't close it this time, but this more like a test issue than anything to do with jtreg or javac, and should be reassigned accordingly.
21-01-2016
The test contains a reference to something called ClassFileInstaller. See these lines in LogTest.java * @run main ClassFileInstaller sun.hotspot.WhiteBox * sun.hotspot.WhiteBox$WhiteBoxPermission Now look at ClassFileInstaller.java /** * Dump a class file for a class on the class path in the current directory / public class ClassFileInstaller { /* * @param args The names of the classes to dump * @throws Exception */ public static void main(String... args) throws Exception { for (String arg : args) { ClassLoader cl = ClassFileInstaller.class.getClassLoader(); // Convert dotted class name to a path to a class file String pathName = arg.replace('.', '/').concat(".class"); InputStream is = cl.getResourceAsStream(pathName); // Create the class file's package directory Path p = Paths.get(pathName); if (pathName.contains("/")) { Files.createDirectories(p.getParent()); } // Create the class file Files.copy(is, p, StandardCopyOption.REPLACE_EXISTING); } } } It's copying .class files around. If you want a smoking gun for how java.util.function.BinaryOperator ends up in test/lib/sun/hotspot/WhiteBox.class, I would start here. This could explain the other issues related to truncated .class files. If another test is concurrently copying bits into a class file being read by another test, then yes, you would likely get errors regarding malformed class files.
21-01-2016
Regarding http://spbef18.ru.oracle.com:9503/runs/01196/1196951.JAVASE.NIGHTLY.VM.GC_Baseline-XXParallel.2015-12-11/1196951.JAVASE.NIGHTLY.VM.GC_Baseline-XXParallel.2015-12-11-73/results/workDir/compiler/compilercontrol/directives/LogTest.jtr This is very (very) strange. Look in the .jtr file to find this error message: ----------System.err:(11/770)---------- /export/local/aurora/CommonData/TESTBASE/hotspot/test/compiler/compilercontrol/share/actions/CompileAction.java:32: error: cannot access WhiteBox import sun.hotspot.WhiteBox; ^ bad class file: /export/local/aurora/sandbox/results/workDir/test/lib/sun/hotspot/WhiteBox.class class file contains wrong class: java.util.function.BinaryOperator Please remove or make sure it appears in the correct subdirectory of the classpath. Note: Some input files use or override a deprecated API. Note that the file appears to be well-formed (as in, not truncated) but it contains the completely wrong class, and moreover it is a class that would normally be in the system image (rt.jar, bootmodules.jimage etc) It is hard to imagine how javac or jtreg could screw up the contents up this file. Is there anything in the hotspot test suite that could overwrite class files?
21-01-2016
Each test from the bugs above builds correctly in clean directory and doesn't rely on any other test. Here is an example: $ mkdir cc; cd cc $ ~/Dev/tools/jtreg/4.1-b12/bin/jtreg -jdk:/Users/ppunegov/Dev/jdk/build/2016-01-11-194748.rwestrel.8139771/ -noreport -v ~/Dev/jdk/hs-comp/hotspot/test/compiler/compilercontrol/commands/PrintTest.java Directory "JTwork" not found: creating runner starting test: compiler/compilercontrol/commands/PrintTest.java runner finished test: compiler/compilercontrol/commands/PrintTest.java Passed. Execution successful Test results: passed: 1 Results written to /Users/ppunegov/Temp/cc/JTwork But it fails in Nightly with java.lang.ClassNotFoundException: compiler.compilercontrol.share.scenario.CommandFileBuilder In JDK-8143550 tests fail with java.lang.ClassFormatError: Truncated class file. If none of tests would build a class, how it could be a broken (truncated)?
21-01-2016
This is typically because of poor test declarations. Every test should contain actions to build the classes it depends on. It should never rely on classes having been compiled by other tests. A good way to check this is to run the test by istelf (just that one test) in a fresh new, empty work directory. If it has inadequate build directives, the test will typically fail to compile. The fix is to update the tests. --- As an analogy, you can think of this as similar to the problem with makefiles, where a target may have inadequate dependencies listed, and may rely on other unrelated targets having executed beforehand to cause the necessary dependencies to be created. When you run such a Makefile concurrent (-j) you'll often get spurious intermittent failures, such as you are observing.
14-01-2016

Duplicate :	JDK-8148012 - get rid of slash-dot-dot in @library directives
Relates :	JDK-8147946 - JTreg incorrectly builds tests with shared classes
Relates :	CODETOOLS-7901527 - jtreg produces class files outside the JTwork directory