United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-7127924 langtools regression tests sometimes fail en-masse on windows
JDK-7127924 : langtools regression tests sometimes fail en-masse on windows

Details
Type:
Bug
Submit Date:
2012-01-07
Status:
Closed
Updated Date:
2012-03-02
Project Name:
JDK
Resolved Date:
2012-03-02
Component:
tools
OS:
windows_xp
Sub-Component:
javac
CPU:
generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
8
Fixed Versions:

Related Reports
Backport:
Relates:
Relates:

Sub Tasks

Description
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

                                    

Comments
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.
                                     
2012-01-07
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.
                                     
2012-01-07
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.
                                     
2012-01-07
SUGGESTED FIX

See:
   http://sa.sfbay.sun.com/projects/langtools_data/8/7127924.0/
                                     
2012-01-18
SUGGESTED FIX

The above fix fails; See the correction in 7131308.
                                     
2012-01-19



Hardware and Software, Engineered to Work Together