Hi Yasumasa, On Tue, Mar 13, 2018 at 9:49 AM, Yasumasa Suenaga <yasue...@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 o...@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.stu...@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.hol...@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 > > > > >
