RFR(S) 8222500: runtime/8176717/TestInheritFD.java failed with java.nio.file.NoSuchFileException: /tmp/communication7071713601211876892.txt

[Harold Seigel]

Hi David,

I don't see how it is possible for any of the test's VM's to delete the 
temp file because there is no code in the test to delete a file.  Files 
created by calling java.io.File.createTempFile() are not automatically 
deleted by the JVM unless java.io.File.deleteOnExit() is called.  This 
test does not make any calls to deleteOnExit() nor to any other file 
deletion API's.

Without this proposed fix, the test's temp files are not deleted at 
all.  You can see this by running the test locally on Linux and then 
looking at /tmp.  You will see that the temp files are still in /tmp 
even after the test successfully completed..

Note that this test has only failed twice with NoSuchFileException in 
the last five months, both times on Linux. So, this is not a Windows issue.

Thanks, Harold

On 5/1/2019 10:51 PM, David Holmes wrote:
> Hi Harold,
>
> On 2/05/2019 4:25 am, Harold Seigel wrote:
>> Hi,
>>
>> Please review this fix for JDK-8222500.  The fix changes the test to 
>> use jdk.test.lib.Utils.createTempFile(), instead of 
>> java.io.File.createTempFile().  This means that the temporary files 
>> will no longer be created in /tmp/, where they can potentially be 
>> changed or deleted by other processes.  And, secondly, that the 
>> temporary files will get cleaned up.
>
> I can't clearly see how the temporary file is used by each VM nor how 
> the VM lifecycles are coordinated. Is it possible that the initial VM 
> could terminate and attempt to delete the file while it is still in 
> use by one of the other VMs? If so that sounds like we will have 
> problems on Windows.
>
> Thanks,
> David
>
>> Open Webrev: 
>> http://cr.openjdk.java.net/~hseigel/bug_8222500/webrev/index.html
>>
>> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8222500
>>
>> The modified test was run successfully on Linux-X64, Mac, and Windows.
>>
>> Thanks, Harold
>>