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:34:25 UTC 2018
- Previous message: RFR: 8199323: hsdis could not be loaded which are located on long path
- Next message: RFR: 8199323: hsdis could not be loaded which are located on long path
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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-Marc h/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/~ys uenaga/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/work space/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/work space/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/9459cab5/attachment-0001.html>
- Previous message: RFR: 8199323: hsdis could not be loaded which are located on long path
- Next message: RFR: 8199323: hsdis could not be loaded which are located on long path
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]