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

[David Holmes]

Hi Harold,

On 3/05/2019 12:00 am, Harold Seigel wrote:
> 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.

Sorry I misunderstood what you meant when you said

"And, secondly, that the temporary files will get cleaned up. "

I thought you meant that the change to Utils.createTempFile was taking 
care of that (by setting deleteOnExit). But you just meant jtreg would 
take care of it.

Aside: we have many dozens of tests in OpenJDK that use 
File.createTempFile, including a few other hotspot tests. We should do a 
general cleanup to fix this.

Thanks,
David
-----

> 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
>>>