JDK 9 RFR of JDK-8156595: java/io/pathNames/GeneralWin32.java fail intermittently on windows-x64
Amy Lu
amy.lu at oracle.com
Tue Dec 20 09:20:45 UTC 2016
Thank you Paul for reviewing this.
The failure is from testcase checkDrivePaths, in which it calls
General.checkNames -> checkSlashes -> checkSlash -> checkNames
public static void checkNames(int depth, boolean create,
String ans, String ask)
throws Exception
{
...
File f = new File(ans);
...
if (f.exists()) {
if (Files.isDirectory(f.toPath(),
LinkOption.NOFOLLOW_LINKS) && f.list() != null) {
347: if ((n = findSomeFile(ans, create)) != null)
348: checkSlashes(d, create, ans + n, ask + n);
...
363: if ((n = f.getParent()) != null) {
...
371: checkSlashes(d, create, n, ask + "..");
}
}
For the failing case, the first time it calls checkNames, the "ans" (the
3rd arg) is "current working dir" (/path/scratch/1).
Then changed to "parent" (/path/scratch) at line 363, and calls
checkSlashes -> checkSlash -> checkNames
checkNames now gets the "parent" (/path/scratch) and at line 347 it may
reach files from other test's working dir (which is not expected to be
tested) and then finally failed at using that file for InputStream in =
new FileInputStream(path).
Ensure test not runs concurrently can also avoid this issue.
Please review the updated webrev:
http://cr.openjdk.java.net/~amlu/8156595/webrev.01
Thanks,
Amy
On 12/20/16 1:47 PM, Paul Sandoz wrote:
> Hi Amy,
>
> I lack the context here so it feels like one is treating the symptoms rather than the cause.
>
> Perhaps it would be better to ensure this test never runs concurrently? is that possible? i believe we did something like that for the streams tests.
>
> Or perhaps the test should isolate it’s data via a temporary directory?
>
> Paul.
>
>> On 19 Dec 2016, at 18:27, Amy Lu <amy.lu at oracle.com> wrote:
>>
>> Please review.
>>
>> Thanks,
>> Amy
>>
>> On 12/5/16 4:23 PM, Amy Lu wrote:
>>> java/io/pathNames/GeneralWin32.java
>>>
>>> When tests run concurrently (-conc:N), it’s possible that this test will walk into and does some testing on other test’s working dir, other than it’s own.
>>>
>>> Please review the patch to avoid this unexpected behavior by restricting the "checkNames" to test's own working directory.
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8156595
>>> webrev: http://cr.openjdk.java.net/~amlu/8156595/webrev.00
>>>
>>> Thanks,
>>> Amy
More information about the core-libs-dev
mailing list