Re: RFR : JDK-8196744 : JMX: Not enough JDP packets received before timeout
Ping! Can I have one more review for the below fix? Thanks Harsha On Monday 26 February 2018 10:42 AM, Harsha Wardhana B wrote: Hello All, Requesting for review from one more reviewer. Thanks Harsha On Wednesday 21 February 2018 10:01 AM, Chris Plummer wrote: Hi Harsha, Not a review, but just a request that you add the explanation of the problem to the CR so we have a record of it. Also, the copyright needs to be updated. thanks, Chris On 2/20/18 3:30 AM, Harsha Wardhana B wrote: Hi All, Please find the fix below for the Jdp test-case. issue: https://bugs.openjdk.java.net/browse/JDK-8196028 webrev : http://cr.openjdk.java.net/~hb/8196028/webrev.00/ Fix details : The test was receiving JDP packets from other VM and hence the multi-cast socket was not timing-out. The default timeout handler was causing test to fail. Added a shutdown method that passes the test in case of timeout. Thanks Harsha
Re: RFR: 8199323: hsdis could not be loaded which are located on long path
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/xx/xx/x/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/xx/xx/x/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
Re: RFR(S): 8198655: test/lib/jdk/test/lib/apps/LingeredApp shouldn't inherit cout/cerr
Hi Chris, On 10/03/2018 6:46 AM, Chris Plummer wrote: Hello, Please help review the following: https://bugs.openjdk.java.net/browse/JDK-8198655 http://cr.openjdk.java.net/~cjplummer/8198655/webrev.00/webrev/ In the end there were two issues. The first was that the pb.redirectError() call was redirecting the LingeredApp's stderr to the console, which we don't want. The second was that nothing was capturing the LingeredApp's output and sending it to the driver app's output (jtr file). These changes make all the LingeredApp's output end up in the jtr file. It isn't clear to me how the interleaving of the two streams by the two threads is handled in the copy routine. Are we guaranteed to get complete lines of output from each stream before writing to System.out? Thanks, David - Tested by running all tests that use LingeredApp. thanks, Chris
