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
