JDK-7127924 : langtools regression tests sometimes fail en-masse on windows
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 8
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: generic
  • Submitted: 2012-01-07
  • Updated: 2012-03-02
  • Resolved: 2012-03-02
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
7u4Fixed 8 b23Fixed
Related Reports
Relates :  
Relates :  
This has happened a few times in integration testing on windows 64 bit.   The symptom is most test fail with this message:

TEST RESULT: Error. Problem deleting file: C:\temp\jprt\P1\185957.jcg-integrator\source\langtools\build\windows-x64\test\langtools\jtreg\JTwork\scratch\classes\Gen.java

SUGGESTED FIX The above fix fails; See the correction in 7131308.

SUGGESTED FIX See: http://sa.sfbay.sun.com/projects/langtools_data/8/7127924.0/

EVALUATION Using the standard jtreg /othervm mechanism is a simple and clever solution, but it does leave open the possibility of the problem example interfering with downstream examples, although admittedly we are not actually seeing that in practice. A somewhat more sophisticated fix would be to run just the one problem example in its own JVM. This could be down by updating Example.Compiler.run to support a new option, "exec", similar to "simple", which execs javac instead of invoking it directly via Main. This could be done by moving the invocation in Example.Compiler:466 to a separate method which be overridden in a subtype of SimpleCompiler which would exec javac in a separate JVM.

EVALUATION Some of the examples under test/tools/javac/diags create a file named Gen.java under the scratch dir. A skeleton class is written to this file. One of these examples, ProcUnclosedTypeFiles, leaves the file open as part of the test. The file never gets explicitly closed. At the start of each example, the files under scratch/ are deleted, but the delete fails silently for this Gen.java if it is still open. jtreg then attempts to delete the files under scratch/ at the start of the next test. If a delete fails, the test fails as an error. On Windows, there have been cases where this Gen.java file stays open throughout the test run. which causes every subsequent test to fail. Note that when the file object is gc'd the file gets closed, so the number of tests that fail, if any, is non-deterministic. Getting this file closed is difficult. As an easy out, we just run these tests in othervm mode which causes the files to be closed when the test terminates.

SUGGESTED FIX Add /othervm to the @run main for the affected tests in test/tools/javac/diags: CheckExamples.java MessageInfo.java RunExamples.java The Gen.java file will be closed when the VM terminates.