RFR(S): 8188122: Path length limits on Windows leads to obscure class loading failures

David Holmes david.holmes at oracle.com
Tue Oct 17 01:26:55 UTC 2017


On 17/10/2017 10:47 AM, Calvin Cheung wrote:
> Hi Ioi,
> 
> On 10/16/17, 4:15 PM, Ioi Lam wrote:
>> Hi Calvin,
>>
>> From your test case:
>>
>>   44     private static final int MAX_PATH = 260;
>>   ...
>>
>>   53         int subDirLen = MAX_PATH - classDir.toString().length() - 2;
>>   54         if (subDirLen > 0) {
>>   55             char[] chars = new char[subDirLen];
>>   56             Arrays.fill(chars, 'x');
>>   57             String subPath = new String(chars);
>>   58             destDir = 
>> Paths.get(System.getProperty("test.classes"), subPath);
>>   59         }
>>   60
>>   61         CompilerUtils.compile(sourceDir, destDir);
>>
>> It looks like at least part of the JDK is able to read and write files 
>> that are in paths longer than 260 characters.
>>
>> For JDK-8188122, it seems the problem exists only with 
>> -Xbootclasspath/a is used. Have you tested if you can use -cp to load 
>> classes from the long directory?
> Yes, the problem exists only with -Xbootclasspath/a because the call 
> path is different comparing with -cp.

The point is if -cp can handle it then -Xbootclasspath must be able to 
handle it too! They both have to read directories!

Thanks,
David

> Call path with -Xbootclasspath/a:
>      ClassPathDirEntry::open_stream() at classLoader.cpp:274 0x7ffff5ca48d0
>      ClassLoader::load_class() at classLoader.cpp:1,412 0x7ffff5ca94a8
>      SystemDictionary::load_instance_class() at 
> systemDictionary.cpp:1,524 0x7ffff671e141
>      SystemDictionary::resolve_instance_class_or_null() at 
> systemDictionary.cpp:847 0x7ffff671bb3f
>      SystemDictionary::resolve_or_null() at systemDictionary.cpp:263 
> 0x7ffff671a1a1
>      SystemDictionary::resolve_or_null() at systemDictionary.cpp:268 
> 0x7ffff671a215
>      JVM_FindClassFromBootLoader() at jvm.cpp:777 0x7ffff6204544
>      Java_java_lang_ClassLoader_findBootstrapClass() at 0x7ffff4a8a0e6
> 
> Call path with -cp:
> 
>      ClassFileParser::fill_instance_klass() at classFileParser.cpp:5,309 
> 0x7ffff5c93a6d
>      ClassFileParser::create_instance_klass() at 
> classFileParser.cpp:5,289 0x7ffff5c938bd
>      KlassFactory::create_from_stream() at klassFactory.cpp:214 
> 0x7ffff63462ef
>      SystemDictionary::resolve_from_stream() at 
> systemDictionary.cpp:1,144 0x7ffff671cadd
>      jvm_define_class_common() at jvm.cpp:943 0x7ffff6205376
>      JVM_DefineClassWithSource() at jvm.cpp:963 0x7ffff620588d
>      Java_java_lang_ClassLoader_defineClass1() at 0x7ffff4a89c68
> 
> Note that ClassPathDirEntry::open_stream() isn't called when -cp is used.
>>
>> If that's the case, maybe we should fix -Xbootclasspath/a so that it 
>> can handle over 260 chars on Windows?
> No easy way of fixing it other than using the unicode version of windows 
> API.
> 
> thanks,
> Calvin
>>
>> Thanks
>>
>> - Ioi
>>
>>
>>
>> On 10/16/17 3:15 PM, Calvin Cheung wrote:
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8188122
>>>
>>> Adding a warning message if the full path or the directory length 
>>> exceeds MAX_PATH on windows.
>>>
>>> Example warning messages.
>>>
>>> 1) The full path exceeds MAX_PATH:
>>>
>>> Java HotSpot(TM) 64-Bit Server VM warning: construct full path name 
>>> failed: total length 270 exceeds max length of 260
>>>     dir 
>>> T:\\testoutput\\jtreg\\JTwork\\classes\\2\\runtime\\LoadClass\\LongPath.d\\xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
>>> length 259
>>>     name Hello.class length 11
>>>
>>> 2) The directory path exceeds MAX_PATH:
>>>
>>> Java HotSpot(TM) 64-Bit Server VM warning: os::stat failed: path 
>>> length 265 exceeds max length 260
>>>     path 
>>> T:\\testoutput\\jtreg\\JTwork\\classes\\2\\runtime\\LoadClass\\LongPath.d\\xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\\xxxxx 
>>>
>>>
>>> webrev:
>>>     http://cr.openjdk.java.net/~ccheung/8188122/webrev.00/
>>>
>>> Testing:
>>>     JPRT (including the new test)
>>>
>>> thanks,
>>> Calvin
>>


More information about the hotspot-runtime-dev mailing list