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

[David Holmes]

Looks fine to me. Just need a second review.

And if you use the new submit-hs repo [1] to do pre-push testing you can 
push this yourself.

Thanks,
David

[1] 
http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-March/030656.html

On 13/03/2018 12:25 AM, Yasumasa Suenaga wrote:
> 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