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

[Harold Seigel]

Thanks David!

I looked at the hotspot tests that call createTempFile().  They all 
either call deleteOnExit() or use some other means to delete the temp file.

Harold

On 5/2/2019 11:12 PM, David Holmes wrote:
> 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
>>>>