RFR: 8199323: hsdis could not be loaded which are located on long path

[Yasumasa Suenaga]

Hi David,

> I don't think this code has the same concern that the code in jvm_md.h claims** to have, so a simple use of MAXPATHLEN should be fine on all non-windows platforms.

It sounds good to me. I updated webrev:
   http://cr.openjdk.java.net/~ysuenaga/JDK-8199323/webrev.01/


> My only concern with the current change is whether a 4K on stack buffer might cause any issues?

In case of HotSpot for x64 Linux, stack size is 1MB. So I think the risk of stack overflow is very low.
In fact, my environment (Fedora 27 x64) works fine with this change.


Thanks,

Yasumasa


On 2018/03/12 13:13, David Holmes wrote:
> Hi Yasumasa,
> 
> On 8/03/2018 11:21 PM, Yasumasa Suenaga wrote:
>> Hi all,
>>
>> Could you review and sponsor it?
>>
>>                            webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8199323/webrev.00/
>>                               JBS: https://bugs.openjdk.java.net/browse/JDK-8199323
>> Mach5 test result on submit repo: mach5-one-ysuenaga-JDK-8199323-20180308-1027-13701
>>
>> I encountered DebuggerException when hsdis is located on long path as below:
>>
>> Location of hsdis:
>> /home/yasuenag/work/xxxxxx/xxxxxxxxxxxxxx/xxxxxxxxxxxxx/workspace/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.101-3.b13.el6_8.x86_64/jre/lib/amd64/hsdis-amd64.so
>>
>> Exception:
>> sun.jvm.hotspot.debugger.DebuggerException: /home/yasuenag/work/xxxxxx/xxxxxxxxxxxxxx/xxxxxxxxxxxxx/workspace/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.101-3.b13.el6_8.x86_64/j: cannot open shared object file: No such file or directory
>>
>> In Java_sun_jvm_hotspot_asm_Disassembler_load_1library(), buffer which uses for library path is defined as below:
>>
>> ```
>> char buffer[128];
>> ```
>>
>> I copied JVM_MAXPATHLEN related code to sadis.c from os/posix/include/jvm_md.h and os/windows/include/jvm_md.h .
> 
> I don't think this code has the same concern that the code in jvm_md.h claims** to have, so a simple use of MAXPATHLEN should be fine on all non-windows platforms.
> 
> ** The posix jvm_md.h code is historical and I don't think we have to be concerned either about a 4095 definition of MAXPATHLEN or that the VM and libraries may have been compiled on different Linux versions!
> 
> My only concern with the current change is whether a 4K on stack buffer might cause any issues?
> 
> Thanks,
> David
> -----
> 
>>
>> I added noreg-hard label on this ticket because this issue is available when disassembling on coredump.
>>
>>
>> Thanks,
>>
>> Yasumasa