RFR: JDK-8213214: Set -Djava.io.tmpdir= when running tests

[Erik Joelsson]

On 2020-06-16 23:25, Sergey Bylokhov wrote:
> As far as I understand this new temp folder will be cleaned after every
> tests run, doesn't it look like a workaround for problematic tests and
> product bugs?
This new tmp folder is created in the jtreg test-support dir (which is 
where we direct the jtreg work dir). It's global for one invocation of 
jtreg. This work dir is cleaned and recreated before a test is run from 
the makefiles. In the local developer case, this means it will stay 
around until you run the same set of tests again, manually delete it, or 
you run "make clean". In a distributed test environment, it will stay 
around until the distributed system decided to clean up the test 
workspace. Like for any artifact created by tests, this is exactly what 
we want.
> Personally, I found many bugs in the tests and some product bugs as
> well, which caused "leakage" of the temporary files.
>
If tests are allowed to write files anywhere outside of the test 
workspace, then they will eventually leak those files, regardless of how 
well implemented the test is, because tests can fail and crash. If tests 
couldn't fail, there would be no reason to run them. When running 
millions of tests every day, those failures add up and fill up disks.
> Probably additionally to this fix we should personalise every temp
> file created in the test context via createTempFile or similar API and
> report the test as failed if the file was not removed at the end?
>
In my opinion, there is very rarely a reason to use createTempFile in a 
test. When trying to investigate a failed test, I always much prefer 
tests that create explicit files in an assigned sandbox/workdir and 
leaving them behind for later inspection. I rather employ a clean first 
strategy (as we do with the workdir from the makefiles), where the test 
is aware that a previous run may have left files around in the known 
locations and deletes them first. As long as these files aren't adding 
up to outrageous amounts of data of course.

/Erik

> On 6/16/20 3:53 pm, Jonathan Gibbons wrote:
>> It would also be good to identify the tests that are using temporary 
>> directories in this manner and have them use the jtreg scratch 
>> directory where possible.
>>
>> -- Jon
>>
>> On 6/16/20 12:22 PM, Erik Joelsson wrote:
>>> (re-sending this as it doesn't look like it was delivered)
>>>
>>> There are a lot of jtreg tests that use temporary files. These 
>>> temporary files add up over time and fill up the global temp 
>>> directories on our test systems. To tackle this, we should try to 
>>> redirect these temporary files into a directory controlled by the 
>>> test framework. Jtreg does not do this, but we can set 
>>> -Djava.io.tmpdir from RunTest.gmk. This will not prevent all temp 
>>> files from being created outside of the work dir, but at least most.
>>>
>>>
>>> I have found one test where this becomes an issue, 
>>> java/nio/file/Path/Misc.java on Windows when running in elevated 
>>> mode with the workspace on a subst drive. This looks like an actual 
>>> issue in the product, so I have filed a separate bug for it [1]. 
>>> Since we currently use subst in our distributed test system to get 
>>> around Windows path length issues, we are hitting this problem. 
>>> While the bug is being evaluated, I have implemented a workaround in 
>>> the test so that it is able to handle the known situation. I would 
>>> like to have someone from core-libs look at the workaround.
>>>
>>> Webrev: http://cr.openjdk.java.net/~erikj/8213214/webrev.01/
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8213214
>>>
>>> /Erik
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8213216
>>>
>>>
>
>