Re: RFR(S): JDK-8157236 - attach on ARMv7 fails with com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file

David, > Thanks, this looks okay. Thank you for review! > Only minor concern is whether we have to > apply casts to the results of geteuid() and st.st_uid when used with > %d format specifier? I didn't see any complains neither from jprt nor building locally. uid_t is 4 byte type for both 32b

Re: RFR(S): *NEED SECOND* JDK-8157236 - attach on ARMv7 fails with com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file

On 2016-08-12 12:04, Dmitry Samersoff wrote: > David, > > Updated webrev is: > > http://cr.openjdk.java.net/~dsamersoff/JDK-8157236/webrev.04/ > > Windows is absolutely different story that requires significant efforts > to reproduce error conditions and test changes. Also it has nothing to > do

RFR: JDK-8164012: com/sun/jdi/CatchPatternTest.sh fails on jdk9/hs with Required output "Exception occurred: java.lang.IllegalMonitorStateException" not found

All, Please review this fix for a test that starting failing after recent changes to java.lang.invoke. The test instructs jdb to break on all exceptions matching "java.lang.I*" (that's a capital 'i'). The semantics of that operation actually means "break on all exceptions which have a class n

Re: RFR: JDK-8164012: com/sun/jdi/CatchPatternTest.sh fails on jdk9/hs with Required output "Exception occurred: java.lang.IllegalMonitorStateException" not found

Staffan, Looks good for me! -Dmitry On 2016-08-15 21:15, Staffan Larsen wrote: > All, > > Please review this fix for a test that starting failing after recent changes > to java.lang.invoke. > > The test instructs jdb to break on all exceptions matching "java.lang.I*" > (that's a capital 'i

Re: RFR: JDK-8164012: com/sun/jdi/CatchPatternTest.sh fails on jdk9/hs with Required output "Exception occurred: java.lang.IllegalMonitorStateException" not found

Thank you! > On 15 aug. 2016, at 20:27, Dmitry Samersoff > wrote: > > Staffan, > > Looks good for me! > > -Dmitry > > > On 2016-08-15 21:15, Staffan Larsen wrote: >> All, >> >> Please review this fix for a test that starting failing after recent changes >> to java.lang.invoke. >> >> The

Re: RFR: JDK-8164012: com/sun/jdi/CatchPatternTest.sh fails on jdk9/hs with Required output "Exception occurred: java.lang.IllegalMonitorStateException" not found

Hi Staffan, Looks good. Though I do wonder how the matching logic works such that the superclass is considered. I suppose it is a "feature" to match on X and all subclasses of X, but probably should be a way to match on exactly X not subclasses. Anyway just idle thoughts. :) Thanks, David

RFR JDK-8152589 : java/lang/management/ThreadMXBean/Locks.java fails intermittently, blocked on wrong object

Hello, Please review and provide comments for fix for issue, https://bugs.openjdk.java.net/browse/JDK-8152589 having webrev located at http://cr.openjdk.java.net/~hb/8152589/webrev.00/ Fix details: 1. From nightly failures we see that LockThreadB was blocked on wrong object. We now do a rep

Re: RFR JDK-8151345 : compiler/codecache/jmx/PeakUsageTest.java is failing on jdk9/dev for JPRT -testset hotspot

Yes. assertEQorGTE can be used. But using assertEQorLTE is better suited as it increase code readability. So I would like to leave that in place. On Saturday 13 August 2016 12:59 AM, Staffan Larsen wrote: If you swap currUsage and peakUsage in the call to assertEQorLTE() you can use assertEQo

Re: RFR 8160913: [TEST_BUG] javax/management/security/SecurityTest.java fails due to missing keyStore file

Hi, Reminder, please help me with this review. Regards, Mallikarjuna Avaluri On 8/9/2016 11:11 AM, Mallikarjuna Avaluri wrote: Hi all, Could you please review fix for following issue. Bug id: https://bugs.openjdk.java.net/browse/JDK-8160913 Summary: [TEST_BUG] javax/management/security/