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

[Yasumasa Suenaga]

Thanks David!

I've run test on submit-hs repo, but I received 1 failure:

mach5-one-ysuenaga-JDK-8199323-20180313-0429-14193
  java/lang/invoke/condy/CondyInterfaceWithOverpassMethods.java
  windows-x64
  Error: failed to clean up files after test

I guess the failure does not relate to this change.
After getting second reviewer, I re-run the test before pushing.


Yasumasa



2018-03-13 16:38 GMT+09:00 David Holmes <david.holmes at oracle.com>:
> 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