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

David Holmes david.holmes at oracle.com
Mon Mar 12 04:13:47 UTC 2018

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 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

More information about the serviceability-dev mailing list