[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    Re: RFR: 8199323: hsdis could not be loaded which are located on long path
From:       David Holmes <david.holmes () oracle ! com>
Date:       2018-03-13 11:22:17
Message-ID: bd9476fc-1a12-0078-e661-d5ba537cf7ef () oracle ! com
[Download RAW message or body]

On 13/03/2018 6:26 PM, Yasumasa Suenaga wrote:
> Thanks David!
> 
> I've run test on submit-hs repo, but I received 1 failure:
> 
> mach5-one-ysuenaga-JDK-8199323-20180313-0429-14193
> java/lang/invoke/condy/CondyInterfaceWithOverpassMethods.java
> windows-x64
> Error: failed to clean up files after test
> 
> I guess the failure does not relate to this change.

No. "failed to clean up files after test" is something we tend to see a 
bit on windows.

> After getting second reviewer, I re-run the test before pushing.

Ok.

David

> 
> Yasumasa
> 
> 
> 
> 2018-03-13 16:38 GMT+09:00 David Holmes <david.holmes@oracle.com>:
> > 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


[prev in list] [next in list] [prev in thread] [next in thread]