RFR: 8199323: hsdis could not be loaded which are located on long path (original) (raw)

Thomas Stüfe thomas.stuefe at gmail.com
Tue Mar 13 08:59:23 UTC 2018

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 JVMMAXPATHLEN. > > 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 jvmmd.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. el68.x8664/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.el68.x8664/j: >>>>> cannot open shared object file: No such file or directory >>>>> >>>>> In JavasunjvmhotspotasmDisassemblerload1library(), buffer which >>>>> uses for library path is defined as below: >>>>> >>>>> _ _>>>>> char buffer[128];_ _>>>>> >>>>> >>>>> I copied JVMMAXPATHLEN related code to sadis.c from >>>>> os/posix/include/jvmmd.h and os/windows/include/jvmmd.h . >>>> >>>> >>>> I don't think this code has the same concern that the code in jvmmd.h >>>> claims** to have, so a simple use of MAXPATHLEN should be fine on all >>>> non-windows platforms. >>>> >>>> ** The posix jvmmd.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>

More information about the serviceability-dev mailing list