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

[Thomas Stüfe]

Hi Yasumasa,

On Tue, Mar 13, 2018 at 9:49 AM, Yasumasa Suenaga <yasuenag at gmail.com>
wrote:

> Thanks Thomas!
>
> I did not understand cause of failure in CondyInterfaceWithOverpassMeth
> ods.java.
> Can you share Mach5 report?
>
>
Sorry, unfortunately no. I'm a reviewer, but not from Oracle :)

You could send a mail to ops at openjdk.java.net. In general, getting detailed
test error information from these new submit repos has been very difficult.


> I want to know I can push this change now.
>
>
> Yasumasa
>
>
Best Regards, Thomas


>
> 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
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20180313/f9ad852a/attachment.html>