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?
Personally, I found many bugs in the tests and some product bugs as
well, which caused "leakage" of the temporary files.
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?
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
--
Best regards, Sergey.
