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

[Yasumasa Suenaga]

Thanks Thomas!

I did not understand cause of failure in CondyInterfaceWithOverpassMethods.java.
Can you share Mach5 report?

I want to know I can push this change now.


Yasumasa



2018-03-13 17:34 GMT+09:00 Thomas Stüfe <thomas.stuefe at gmail.com>:
> Hi Yasumasa,
> looks fine to me too. Thank you for fixing.
>
> Like David, not a big fan of the array allocation on the stack, but it will
> probably be okay. Lets hope noone changes JVM_MAXPATHLEN.
>
> Best Regards, Thomas
>
> On Tue, Mar 13, 2018 at 8:38 AM, David Holmes <david.holmes at oracle.com>
> wrote:
>>
>> 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
>
>