Re: [TestBug] RFR : JDK-8192909 - Invalid username or password in HashedPasswordFileTest.java
Thanks Christoph for the review. Can I get one more review please? -Harsha On Tuesday 05 December 2017 11:29 AM, Langer, Christoph wrote: Hi Harsha, this looks good to me. Small finding: Line 366, there could be a space between if and (. Best regards Christoph -Original Message- From: serviceability-dev [mailto:serviceability-dev- boun...@openjdk.java.net] On Behalf Of Harsha Wardhana B Sent: Montag, 4. Dezember 2017 19:28 To: serviceability-dev@openjdk.java.net Subject: [TestBug] RFR : JDK-8192909 - Invalid username or password in HashedPasswordFileTest.java Hi All, Please review and provide comments for fix for, issue: https://bugs.openjdk.java.net/browse/JDK-8192909 having webrev at, webrev : http://cr.openjdk.java.net/~hb/8192909/webrev.00/ Fix details: The test was failing intermittently because of duplicate entries for role in input password file. The duplicate entries get over-written by JMX agent, but the client was testing with stale entries for duplicated role. Also, the test now uses a single random number generator from test package (Utils.getRandomInstance) instead of two. Regards Harsha
RE: [TestBug] RFR : JDK-8192909 - Invalid username or password in HashedPasswordFileTest.java
Hi Harsha, this looks good to me. Small finding: Line 366, there could be a space between if and (. Best regards Christoph > -Original Message- > From: serviceability-dev [mailto:serviceability-dev- > boun...@openjdk.java.net] On Behalf Of Harsha Wardhana B > Sent: Montag, 4. Dezember 2017 19:28 > To: serviceability-dev@openjdk.java.net > Subject: [TestBug] RFR : JDK-8192909 - Invalid username or password in > HashedPasswordFileTest.java > > Hi All, > > Please review and provide comments for fix for, > > issue: https://bugs.openjdk.java.net/browse/JDK-8192909 > > having webrev at, > > webrev : http://cr.openjdk.java.net/~hb/8192909/webrev.00/ > > Fix details: The test was failing intermittently because of duplicate > entries for role in input password file. The duplicate entries get > over-written by JMX agent, but the client was testing with stale entries > for duplicated role. Also, the test now uses a single random number > generator from test package (Utils.getRandomInstance) instead of two. > > Regards > > Harsha
Re: RFR(S): 8192978: Missing checks and small fixes in jdwp library
Hi Christoph, Some of your changes could use explanations. Can you please elaborate on the problems you are fixing in the CR? Test cases, or at least explaining how to reproduce the issues you are fixing would also be useful. shmemBase.c: seems correct, but could use explanation/example of when existing code was failing. VirtualMachineImpl.c: When/why is pos ever null? error_messages.c: Is there any reason not to do this fix for all platforms? Do you have a test case for it? error_messages.h: ok. looks like just whitespace cleanup eventHelper.c: Do you have a testcase? Also, is the "bagAdd(eventBag)" message going to be of use to the user? inStream.c: inStream_init() now uses a magic number of 11. What does it represent? inStream_endOfInput() looks like it used to be completely broken. How was this not noticed? Is this related to the change inStream_init(), which possible was masking this error? Is there a test case for it? invoker.c: ok: looks like just whitespace cleanup log_messages.c: is there any reason not to do this fix for all platforms? Do you have a test case for it? I think you will need to file separate CRs for each issue. You can lump the whitespace cleanup into one. The rest probably should each be seaprate CRs, but I could see possibly doing just one CR for them if the CR documented each problem being fixed. thanks, Chris On 12/4/17 7:44 AM, Langer, Christoph wrote: Hi, I’d like to contribute a few fixes that have been done in our JDK builds that add a few additional checks and cleanups. Can I please get a review. Bug: https://bugs.openjdk.java.net/browse/JDK-8192978 WebRev: http://cr.openjdk.java.net/~clanger/webrevs/8192978.0/ Thanks, Christoph
[TestBug] RFR : JDK-8192909 - Invalid username or password in HashedPasswordFileTest.java
Hi All, Please review and provide comments for fix for, issue: https://bugs.openjdk.java.net/browse/JDK-8192909 having webrev at, webrev : http://cr.openjdk.java.net/~hb/8192909/webrev.00/ Fix details: The test was failing intermittently because of duplicate entries for role in input password file. The duplicate entries get over-written by JMX agent, but the client was testing with stale entries for duplicated role. Also, the test now uses a single random number generator from test package (Utils.getRandomInstance) instead of two. Regards Harsha
RE: RFR: 8192897: NPE occurs on clhsdb jstack
Fix looks good Yasumasa. Thanks, Sharath (Not a Reviewer) -Original Message- From: Yasumasa Suenaga [mailto:yasue...@gmail.com] Sent: Saturday, December 02, 2017 4:19 AM To: Sharath Ballal; serviceability-dev@openjdk.java.net Subject: Re: RFR: 8192897: NPE occurs on clhsdb jstack Hi Sharath, I confirmed this issue with jshell and ClhsdbJstack with this change. You need to run the VM in current jdk/hs. Thanks, Yasumasa On 2017/12/02 1:22, Sharath Ballal wrote: > Hi Yasumasa, > I tried jhsdb with a simple HelloWorld (with -Xcomp) and did not see any > exception. > Your app does anything else ? > > Thanks, > Sharath > > > -Original Message- > From: Yasumasa Suenaga [mailto:yasue...@gmail.com] > Sent: Friday, December 01, 2017 7:26 PM > To: serviceability-dev@openjdk.java.net > Subject: RFR: 8192897: NPE occurs on clhsdb jstack > > Hi all, > > I saw NPE when I run jstack on clhsdb as below: > > > hsdb> jstack > Deadlock Detection: > > No deadlocks found. > > "NonBlockingInputStreamThread" #27 daemon prio=5 tid=0x7f0924674000 > nid=0xf429 in Object.wait() [0x7f08cf6fd000] > java.lang.Thread.State: WAITING (on object monitor) > JavaThread state: _thread_blocked > - java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be > imprecise) > - waiting on Error occurred during > stack walking: > java.lang.NullPointerException > at > jdk.hotspot.agent/sun.jvm.hotspot.runtime.CompiledVFrame.getMonitors(CompiledVFrame.java:131) > at > jdk.hotspot.agent/sun.jvm.hotspot.runtime.JavaVFrame.printLockInfo(JavaVFrame.java:125) > at > jdk.hotspot.agent/sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:114) > at > jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor$26.doit(CommandProcessor.java:1073) > at > jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1964) > at > jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1934) > at > jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1814) > at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:99) > at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:40) > at > jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runCLHSDB(SALauncher.java:191) > at > jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:439) > > > It is caused by CompiledVFrame#getScope() returns null. > We should consider it at CompiledVFrame#getMonitors(). > > I uploaded a webrev. Could you review it? > I checked this change with hotspot/jtreg/serviceability/sa on Linux x64. > >http://cr.openjdk.java.net/~ysuenaga/JDK-8192897/webrev.00/ > > We can reproduce this issue when we run the app with -Xcomp option. > So I changed ClhsdbJstack.java to run with it. > > > I cannot access mach5 and JPRT. So I need sponsor. > > > Thanks, > > Yasumasa >
RFR(S): 8192978: Missing checks and small fixes in jdwp library
Hi, I'd like to contribute a few fixes that have been done in our JDK builds that add a few additional checks and cleanups. Can I please get a review. Bug: https://bugs.openjdk.java.net/browse/JDK-8192978 WebRev: http://cr.openjdk.java.net/~clanger/webrevs/8192978.0/ Thanks, Christoph
Re: RFR: 8192897: NPE occurs on clhsdb jstack
Hi Yasumasa, Thanks for this. Looks good. Thanks, Jini. (Not a Reviewer). On 12/1/2017 7:26 PM, Yasumasa Suenaga wrote: Hi all, I saw NPE when I run jstack on clhsdb as below: hsdb> jstack Deadlock Detection: No deadlocks found. "NonBlockingInputStreamThread" #27 daemon prio=5 tid=0x7f0924674000 nid=0xf429 in Object.wait() [0x7f08cf6fd000] java.lang.Thread.State: WAITING (on object monitor) JavaThread state: _thread_blocked - java.lang.Object.wait(long) @bci=0 (Compiled frame; information may be imprecise) - waiting on Error occurred during stack walking: java.lang.NullPointerException at jdk.hotspot.agent/sun.jvm.hotspot.runtime.CompiledVFrame.getMonitors(CompiledVFrame.java:131) at jdk.hotspot.agent/sun.jvm.hotspot.runtime.JavaVFrame.printLockInfo(JavaVFrame.java:125) at jdk.hotspot.agent/sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:114) at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor$26.doit(CommandProcessor.java:1073) at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1964) at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1934) at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1814) at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:99) at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:40) at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runCLHSDB(SALauncher.java:191) at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:439) It is caused by CompiledVFrame#getScope() returns null. We should consider it at CompiledVFrame#getMonitors(). I uploaded a webrev. Could you review it? I checked this change with hotspot/jtreg/serviceability/sa on Linux x64. http://cr.openjdk.java.net/~ysuenaga/JDK-8192897/webrev.00/ We can reproduce this issue when we run the app with -Xcomp option. So I changed ClhsdbJstack.java to run with it. I cannot access mach5 and JPRT. So I need sponsor. Thanks, Yasumasa
