Re: RFR 8193879: Java debugger hangs on method invocation

Looks OK to me. On 10/4/18 5:19 PM, Daniil Titov wrote: Hi Gary and Chris, Please review an updated version of the patch that has newly added test for the case when suspend policy is set to SUSPEND_EVENT_THREAD reimplemented using JDI API. Thus, the changes in src/jdk.jdi/share/classes/com/s

Re: RFR: JDK-8206330: Revisit com/sun/jdi/RedefineCrossEvent.java

On 10/17/18 2:04 PM, Chris Plummer wrote: Hi Gary, Can this be on one line now:   30  * @modules   31  *  jdk.jdi OK What are you blocking all jdk.* classes from redef when you pointed out that only jdk.internal.* is an issue? The file I'm modifying already has some blocking checks

Re: RFR 8211736: jdb doesn't print prompt when breakpoint is hit and suspend policy is STOP_EVENT_THREAD

It's not clear to me if the omitted location information for the non stopping cases was intentional or not. It may be sufficient to know that the event fired without the extra information. I don't think a settable prompt is required either. There are plenty of jdb commands that could be used w

Re: КАК JDK-8212665: com/sun/jdi/DeferredStepTest.java: jj1 (line 57) - unexpected. lastLine=52, minLine=52, maxLine=55

Looks good to me. Should the comment "58 steps" be "58 stops"? On 10/18/18 6:42 PM, Alex Menkov wrote: Hi all, Please review small test fix for https://bugs.openjdk.java.net/browse/JDK-8212665 webrev: http://cr.openjdk.java.net/~amenkov/deferredStep_endOfCycle/webrev/ The test verifies that

Re: RFR: JDK-8210337: runtime/NMT/VirtualAllocTestType.java failed on RuntimeException missing from stdout/stderr

olaris Hard to see how to get a transient EACCES when opening a file ... though as it is really a door I guess there could be additional complexity. David On 3/10/2018 7:54 AM, Chris Plummer wrote: On 10/2/18 2:38 PM, David Holmes wrote: Chris, On 3/10/2018 6:57 AM, Chris Plummer wrote: O

Re: RFR: (S): JDK-8213323: sa/TestJmapCoreMetaspace.java and sa/TestJmapCore.java fail with ZGC

Looks OK to me. On 11/9/18 1:40 AM, Jini George wrote: Hello! Requesting reviews for a small change for disabling the testing of TestJmapCoreMetaspace.java and TestJmapCore.java with ZGC. The change also includes skipping of creating the heapdump file with jmap if the GC being used is ZGC.

Re: RFR 8205654: serviceability/dcmd/framework/HelpTest.java timed out

Looks good to me. You'll need the build directive in HelpTest and InvalidCommandTest. + * @build TestJavaProcess On 11/10/18 12:18 AM, Daniil Titov wrote: Please review the change that fixes serviceability/dcmd/framework/* tests from a time out. The fix for JDK-8166642 made serviceability/dc

Re: JDK-8176828: jtools do not list VM process launched with the debugger option suspend=y

On 11/28/18 4:12 PM, Chris Plummer wrote: On 11/28/18 11:52 AM, Gary Adams wrote: https://bugs.openjdk.java.net/browse/JDK-8156537   - Added a fix for module naming https://bugs.openjdk.java.net/browse/JDK-8176533   - Fixed a regression from JDK-816537 that prevented "jcmd " from sending

Re: RFR: JDK-821430: .attach_pid files may remain in the process cwd

I have not refreshed the webrev, yet. Waiting to see if there are any additional comments before updating the webrev. The spaces and the assignments you noticed have been fixed. On 11/29/18 5:27 PM, JC Beyler wrote: Hi Gary, Somehow I still see the same webrev? Has it been updated and my brow

Re: JDK-8176828: jtools do not list VM process launched with the debugger option suspend=y

"run" command 23922 jdk.jcmd/sun.tools.jcmd.JCmd -l 23771 jdk.jdi/com.sun.tools.example.debug.tty.TTY -attach 5900 22526 my We could also pull out the perfmemory set accessible step and set it explicitly. ... On 11/28/18 11:10 PM, David Holmes wrote: I've been lurkin

Re: RFR: JDK-821430: .attach_pid files may remain in the process cwd

Updated webrev:   http://cr.openjdk.java.net/~gadams/8214300/webrev.01/ On 11/30/18 3:10 PM, Chris Plummer wrote: ...and I've been waiting for the webrev update to give it a thumbs up. Chris On 11/30/18 1:11 AM, gary.ad...@oracle.com wrote: I have not refreshed the webrev, yet. Waiti

Re: RFR(XS): 8215042: Move serviceability/sa tests from tier1 to tier3.

Looks OK to me. On 12/8/18 12:53 AM, Leonid Mesnik wrote: Hi Could you please review following fix which moves SA tests from tier1 to tier3. There are some bugs which cause intermittent failures of any test. SA tests fail intermittently are not stable enough for tier1. However failures are no

Re: RFR: JDK-8051349: nsk/jvmti/scenarios/sampling/SP06/sp06t003 fails in nightly

On 12/14/18 4:43 PM, Chris Plummer wrote: On 12/14/18 5:28 AM, Gary Adams wrote: BTW, I forgot to ask if you can fix the typo in the following comment:  345 /* check frame equalaty */ Yes, I fixed that one on Fri. I usually save the typos for the final webrev. On 12/13/18, 11:51

Re: RFR: JDK-8051349: nsk/jvmti/scenarios/sampling/SP06/sp06t003 fails in nightly

Updated webrev:   http://cr.openjdk.java.net/~gadams/8051349/webrev.02/index.html On 12/15/18 8:15 AM, gary.ad...@oracle.com wrote: On 12/14/18 4:43 PM, Chris Plummer wrote: On 12/14/18 5:28 AM, Gary Adams wrote: BTW, I forgot to ask if you can fix the typo in the following comment:  345

Re: RFR: JDK-8211343: nsk_jvmti_parseoptions should handle multiple suboptions

On 12/21/18 2:31 PM, Chris Plummer wrote: Hi Gary, This is much better. Just one question and a couple of minor comments: The original code had the following:  225 context.options.string = (char*)malloc(len + 2); ...  231 strncpy(context.options.string, options, len);  232 context.

Re: RFR: JDK-8211343: nsk_jvmti_parseoptions should handle multiple suboptions

On 12/21/18 3:33 PM, serguei.spit...@oracle.com wrote: Hi Gary, Looks good in general. Thank you for taking care about this! A couple of comments. It seems, with your fixes the macro NSK_JVMTI_OPTION_VAL_SEP is not needed anymore. Also, I wonder if it makes sense to continue using: 238 value

Re: RFR(S): 8215975: [testbug] Adapt nsk tests to the PPC, S390 and AIX platforms.

Would it make sense to add a method to test/lib/jdk/test/lib/Platform.java similar to sharedLibraryExt() to cover the envName setting? Are the other places DYLD_LIBRARY_PATH is set also need to be updated for AIX? On 12/31/18 8:48 AM, Lindenmaier, Goetz wrote: Hi, Some of the nsk tests are no

Re: RFR(S): 8215975: [testbug] Adapt nsk tests to the PPC, S390 and AIX platforms.

Here are few more DYLD_LIBRARY_PATH locations that would be worth checking ./jdk/vm/JniInvocationTest.java:50: env.compute("DYLD_LIBRARY_PATH", (k, v) -> (k == null) ? libdir : v + ":" + libdir); ./jdk/tools/launcher/ExecutionEnvironment.java:66:    ? "DYLD_LIBRARY_PATH" ./jdk/tools/lau

Re: RFR: JDK-8211343: nsk_jvmti_parseoptions should handle multiple suboptions

Here's a revised webrev.   Webrev: http://bussund0416.us.oracle.com/export/users/gradams/work/webrevs/8211343/webrev.01/ Updates in this round of changes :   - replaced index() with strchr() to avoid platform dependent issues with strings.h include   - removed NSK_JVMTI_OPTION_VAL_SEP   - re

Re: RFR: JDK-8211343: nsk_jvmti_parseoptions should handle multiple suboptions

8 10:06 AM, gary.ad...@oracle.com wrote: Here's a revised webrev.   Webrev: http://bussund0416.us.oracle.com/export/users/gradams/work/webrevs/8211343/webrev.01/ Updates in this round of changes :   - replaced index() with strchr() to avoid platform dependent issues with strings.h inclu

RFR: JDK-8158066: SourceDebugExtensionTest fails to rename file

SourceDebugExtensionTest was placed on the ProblemList because of filesystem rename issues on Windows 2012 test systems. The test does not appear to fail on the current mach5 test systems. There was some question concerning symbolic links that might have been problematic at that time. Additional t

Re: RFR: JDK-8158066: SourceDebugExtensionTest fails to rename file

more robust before removing SourceDebugExtensionTest from the problem list. On 1/10/19 8:28 PM, David Holmes wrote: Hi Gary, On 10/01/2019 11:02 pm, gary.ad...@oracle.com wrote: SourceDebugExtensionTest was placed on the ProblemList because of filesystem rename issues on Windows 2012 test systems

Re: RFR: JDK-8158066: SourceDebugExtensionTest fails to rename file

  } if (!tmpFile.renameTo(inOutClassFile)) { Testing in progress ... On 1/11/19, 7:40 AM, David Holmes wrote: Hi Gary, On 11/01/2019 9:22 pm, gary.ad...@oracle.com wrote: After ~1000 testruns I hit a failure in MangleTest and a jtreg agent communication issue with SourceDebu

Re: RFR: JDK-8215550: Debugger does not work after reattach

Issuing a "cont" in the second session does not work, because the threads are not suspended. It's interesting that the thread ids have all changed in the reconnected session. ... main[1] threads Group system:   (java.lang.ref.Reference$ReferenceHandler)0x374 Reference Handler running   (java.la

Re: RFR: JDK-8215550: Debugger does not work after reattach

s. So the first time the agent needs to send a threadID to the debugger, it needs to create a new one. Chris On 1/29/19 1:52 PM, gary.ad...@oracle.com wrote: Issuing a "cont" in the second session does not work, because the threads are not suspended. It's interesting that the thre

Re: RFR: JDK-8065773: JDI: UOE is not thrown, when redefineClasses changes a class modifier

I'm willing to do the leg work on cleaning up the tests, but I'll need some help identifying where the redefine operations are missing the inner_class_flags checks. Is spec change or a CSR required when we change the current behavior to be more strict? On 2/8/19 9:24 PM, David Holmes wrote:

RFR: JDK-8218754: JDK-8068225 regression in JDIBreakpointTest

The recent change to JDK-8068225 changed the order of operations in Debugee.endDebugee() to wait for the debugee to exit before disposing of the vm on the debugger side of the connection. For the tests based on JDIBreakpointTest the debuggee exit status is not used and the tests relied on the debu

Re: RFR: JDK-8218754: JDK-8068225 regression in JDIBreakpointTest

peration induces the debugee to exit. Thanks, David On 2/12/19, 6:59 AM, David Holmes wrote: Hi Gary, On 12/02/2019 8:08 pm, gary.ad...@oracle.com wrote: The recent change to JDK-8068225 changed the order of operations in Debugee.endDebugee() to wait for the debugee to exit before dispos

Re: RFR: JDK-8066993: nsk.jdi.EventRequest.setEnabled.setenabled003 fails: event IS NOT a breakpoint

Right now I'm proposing we use the bug number that matches the entry in the ProblemList to remove the test from the ProblemList. The other matching rules that were added for connection closed and the other bugs with connection closed had no valid reason for attaching to a bug with a specific err

Re: RFR(S): 8218941: jdb should support a dbgtrace command that acts the same as the dbgtrace command line option

Do you need placeholder entries in the translated TTYResources message files? On 2/13/19 9:43 PM, Chris Plummer wrote: Hi, Please review the following: http://cr.openjdk.java.net/~cjplummer/8218941/webrev https://bugs.openjdk.java.net/browse/JDK-8218941 Tested by running the following on all

Re: RFR: JDK-8149461: jmap kills process if non-java pid is specified in the command line

Let me clarify a few things about the proposed fix. The VirtualMachine.list() mechanism is based on Java processes that are up and running. During VM startup when agent libraries are loaded, the fact is recorded in the filesystem that a Java process is eligible for an attach request. This is a m

Re: RFR: JDK-8149461: jmap kills process if non-java pid is specified in the command line

ttp://bernd.eckenfels.net *Von:* Gary Adams *Gesendet:* Freitag, Februar 15, 2019 2:19 PM *An:* gary.ad...@oracle.com *Cc:* Bernd Eckenfels; OpenJDK Serviceability *Betreff:* Re: RFR: JDK-8149461: jmap kills process if non-jav

Re: RFR: JDK-8219388: Misleading log message "issuspended002a debuggee launched"

Sorry, my bad, used the wrong list of files when I made the webrev. Added the location, interrupt and setvalue debuggee references.   Webrev: http://cr.openjdk.java.net/~gadams/8219388/webrev.01/ On 2/19/19 3:01 PM, Chris Plummer wrote: Hi Gary, On 2/19/19 11:38 AM, Gary Adams wrote: On my fi

Re: RFR: JDK-4903717: nsk/jdi/ThreadReference/isSuspended/issuspended002 failing

The commented out "docontinue" was done to match the style used in the other tests. I'll remove it for this test. In any event, the test still is failing 8 / 500 testruns on macosx and windows debug builds. The change is not sufficient. Here's a recent failure. You can see in the log that the d

Re: RFR: JDK-4903717: nsk/jdi/ThreadReference/isSuspended/issuspended002 failing

{ 162 log("entered into block: synchronized (waitnotifyObj)"); 163 waitnotifyObj.notify(); } Thanks, Serguei On 2/21/19 10:57, gary.ad...@oracle.com wrote: The commented out "docontinue" was done to match the style used in

Re: RFR: JDK-4903717: nsk/jdi/ThreadReference/isSuspended/issuspended002 failing

the thread2 reaching the desired breakpoint.   Updated webrev: http://cr.openjdk.java.net/~gadams/4903717/webrev.01/ Changes in this iteration:   - cosmetic changes - spaces around operators - removed extra spaces around parens      - removed extra blank lines - fixed typo in ERRROR

Re: RFR: JDK-4903717: nsk/jdi/ThreadReference/isSuspended/issuspended002 failing

. Testing is in progress. On 2/26/19 3:49 PM, gary.ad...@oracle.com wrote: New fix will be coming tomorrow... I dumped the main and thread2 stacks at the point of the timeout and found they were both contending for the java.io.PrintStream writeln() synchronization block. While writing log messages

Re: RFR: JDK-8220295: sun/tools/jps/TestJps.java still timing out

Neither of these tests has been reproduced under controlled conditions. On recent test runs, I've been more likely to see a jstat or jstatd test failing. On 3/11/19 2:49 PM, Chris Plummer wrote: Have you been able to reliably reproduce either of these issues? Chris On 3/11/19 9:50 AM, Gary A

Re: RFR(XS): 8220352: Crash with assert(external_guard || result != __null) failed: Invalid JNI handle

Looks good to me. On 3/13/19 2:28 AM, Chris Plummer wrote: Hi, Please review the following: https://bugs.openjdk.java.net/browse/JDK-8220352 http://cr.openjdk.java.net/~cjplummer/8220352/webrev.00/ The possible use of an invalid jni handle is being avoided by not deleting the globalrefs as t

Re: RFR (S): 8220451: jdi/EventQueue/remove/remove004 failed due to "ERROR: thread2 is not alive"

I'm fine with Nick's solution. I can help with the bug resolution after the changes are pushed. The only thought I'd add is that someday we should revisit all these time based mechanisms. It would be a lot cleaner to have the debugger always single the debuggee when it is time to quit. There

RFR: JDK-8203026: java.rmi.NoSuchObjectException: no such object in table

Here's a proposed fix for the intermittent jstatd test failure. By moving the exported object from a local method variable to a static class variable a strong reference is held so the object will not be garbage collected prematurely.   Webrev: http://cr.openjdk.java.net/~gadams/8203026/webrev.00/

RFR: JDK-8221164: jstatLineCounts tests need to be more resilient for NaN outputs

The M and CCS columns from jstat output can present a dash("-") for NaN values, such as : --System.out:(13/1261)-- S0 S1 E O M CCSYGC YGCTFGCFGCTCGC CGCT GCT 0.00 0.00 0.00 0.00 - - 00.000 00.00

RFR: JDK-8220295: sun/tools/jps/TestJps.java still timing out

This proposed change will configure the sun/tools/j* and com/sun/tools/attach tests to be labeled as jtreg exclusiveAccess.dirs so the java attaching tests are not run concurrently. There is only annecdotal observations that multiple tools are running when these tests are timing out. 1000s of tes

Re: RFR: JDK-8221164: jstatLineCounts tests need to be more resilient for NaN outputs

19 1:18 AM, gary.ad...@oracle.com wrote: The M and CCS columns from jstat output can present a dash("-") for NaN values, such as : --System.out:(13/1261)-- S0 S1 E O M CCSYGC YGCTFGCFGCTCGC CGCT GCT 0.00

Re: RFR: JDK-8220295: sun/tools/jps/TestJps.java still timing out

/19 3:32 PM, Chris Plummer wrote: Hi Gary, The changes look fine, but are you going to file the CRs I suggested (one for jtreg exclusiveAccess.dirs help text and one to further look into this issue)? thanks, Chris On 3/22/19 1:38 AM, gary.ad...@oracle.com wrote: This proposed change will

Re: RFR: JDK-8218128: vmTestbase/nsk/jvmti/ResourceExhausted/resexhausted003 and 004 use wrong path to test classes

The stab at catching the OOME was added to try an diagnose some of the remaininf failures. The tests will remain on the ProblemList. Probably best to remove the extra debugging and start fresh when the other issues are investigated. On 3/26/19 1:56 AM, David Holmes wrote: On 26/03/2019 3:34

Re: 8221532: Incorrect copyright header in FileSystemSupport_md.c

Looks good to me . On 3/27/19 2:58 PM, Daniil Titov wrote: Hi Chris, Please review a new version of the webrev that corrects this. Webrev: http://cr.openjdk.java.net/~dtitov/8221532/webrev.02/ Bug: https://bugs.openjdk.java.net/browse/JDK-8221532 Thanks! --Daniil On 3/27/19, 11:46 AM, "Chri

RFR: JDK-8223584 -Exclude javax/management/remote/mandatory/connection/MultiThreadDeadLockTest.java until JDK-8042215 is fixed

Another trivial update to ProblemList an intermittent failing test. diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt --- a/test/jdk/ProblemList.txt +++ b/test/jdk/ProblemList.txt @@ -567,6 +567,7 @@  java/lang/management/ThreadMXBean/AllThreadIds.java 8131745 generic-all  javax/

RFR: JDK-8218701: jdb tests failed with AGENT_ERROR_INVALID_THREAD

This proposed workaround ensures that the delay between a suspend request passing through the jdwp command queue will not fail due to a no longer running thread.   Webrev: http://cr.openjdk.java.net/~gadams/8218701/webrev/   Issue: https://bugs.openjdk.java.net/browse/JDK-8218701

Re: RFR (XS): 8223718: Checks in check_slot_type_no_lvt() should be always executed

Be sure to check copyright dates and line lengths. On 5/29/19 6:24 PM, serguei.spit...@oracle.com wrote: Please, review fix for:   https://bugs.openjdk.java.net/browse/JDK-8223718 Webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8223718-jvmti-getlocal.1/ Summary:   The JVMTI GetLo

Re: RFR: 8222828: vmTestbase/nsk/jdi/BScenarios/multithrd/tc02x004/TestDescription.java failed

Looks good to me. Any other graal test timeouts that might be addressed in a similar manner? On 6/7/19 2:47 PM, Daniil Titov wrote: Please review the change that fixes an intermittent failure of the test when it is run with Graal on. The test starts a debuggee and sets the method entry breakp

RFR: JDK-8224642: Test sun/tools/jcmd/TestJcmdSanity.java fails: Bad file descriptor

The workaround below passed 1000 testruns on linux-x64-debug. A more localized fix simply moves the stream reader out of the try with resources, so only one close is applied to the underlying socket. I'll run this test through 1000 testruns today. Looking for a final review for this change. dif

Re: JDK-8224642: Test sun/tools/jcmd/TestJcmdSanity.java fails: Bad file descriptor

So you prefer the fix in VirtualMachineImpl SocketInputStream close() rather than the JCmd try with resources. If we were dealing with output streams, it would be important to apply the flush to the writer. Since these are input streams we just need to guard against the duplicate close for the na

Re: RFR: JDK-8224642: Test sun/tools/jcmd/TestJcmdSanity.java fails: Bad file descriptor

instance. But if you do that, you should at least open a bug to track fixing of the InputStream implementation... Best regards Christoph -Original Message- From: serviceability-dev boun...@openjdk.java.net> On Behalf Of gary.ad...@oracle.com Sent: Dienstag, 18. Juni 2019 12:08 T

Re: (13) RFR (XS): 8226917: jvmti/scenarios/contention/TC04/tc04t001/TestDescription.java fails on jvmti->InterruptThread (JVMTI_ERROR_THREAD_NOT_ALIVE)

Looks good to me. On 6/28/19 2:09 PM, serguei.spit...@oracle.com wrote: Please, review a test bug fix for: https://bugs.openjdk.java.net/browse/JDK-8226917 Webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8226917-mon-events-correction2.1/ Summary:   One more fragment in the native

Re: RFR [XS] : 8226943: compile error in libfollowref003.cpp with XCode 10.2 on macosx

I believe you will find in the generate jvmti.h header file that both enumerations had assigned value of 3. That could explain why a less type strict version of the compiler would not have complained. On 6/28/19 3:04 PM, David Holmes wrote: Hi Matthias, Dropped build-dev and added serviceabilit

Re: RFR: JDK-8180709: java -javaagent:agent.jar with run-time that does not contain java.instrument prints confusing error

The only legitimate reason libinstrument would be missing is if java.instrument was not included. Any other speculation about why libinstrument was not found is hard to explain. e.g. until the vm is initialized we can not explicitly say whether java.instrument module is present or not. On 12/

Re: RFR: JDK-8180709: java -javaagent:agent.jar with run-time that does not contain java.instrument prints confusing error

I can just the error message. What would you like it to say? "Module java.instrument may be missing" On 12/18/17 4:09 PM, serguei.spit...@oracle.com wrote: Hi Gary, I have the same concern and like Chris's suggestion. The JMX case must be simpler as there is no need to load the agent library

Re: RFR: JDK-8188856: Incorrect file path in an exception message when .java_pid is not accessible on Unix

On 12/18/17 2:26 PM, Chris Plummer wrote: Hi Gary, On 12/18/17 6:47 AM, Gary Adams wrote: Here's a simple fix to correct the error message when the java_pid socket is not found. The code previously reported the attach_pid file name rather than the socket file name that was not found.   Issue:

Re: RFR: JDK-8188856: Incorrect file path in an exception message when .java_pid is not accessible on Unix

refreshed webrev is available     Webrev: http://cr.openjdk.java.net/~gadams/8188856/webrev.01/ On 12/18/17, 4:38 PM, Chris Plummer wrote: On 12/18/17 1:22 PM, gary.ad...@oracle.com wrote: On 12/18/17 2:26 PM, Chris Plummer wrote: Hi Gary, On 12/18/17 6:47 AM, Gary Adams wrote: Here's a

Re: RFR: JDK-8180709: java -javaagent:agent.jar with run-time that does not contain java.instrument prints confusing error

http://cr.openjdk.java.net/~gadams/8180709/webrev.01/ On 12/19/17, 5:10 AM, Alan Bateman wrote: On 18/12/2017 21:14, gary.ad...@oracle.com wrote: I can just the error message. What would you like it to say? "Module java.instrument may be missing" Technically it may be that the java.instrumen

RFR: 6640188: Methods com.sun.tools.attach.VirtualMachine.load... don't throw NullPointerException

Here's a simple fix to add explicit checks for the loadAgentXXX methods to ensure NPE is thrown when null arguments are passed. Several other management methods have similar provider not null checks, they just were not present for agent path and library methods. This should remove the spec ambi

Re: RFR: JDK-8031482: Some jcmd commands generate output with \n as a line separator instead of \r\n on Windows

Webrev updated with buffered reader lines() suggested by David.   http://cr.openjdk.java.net/~gadams/8031482/webrev.01/ On 1/11/18 11:28 AM, Gary Adams wrote: Here's a simple fix to the split pattern when output lines are using mixed line separators in the same outputstream . e.g. split("\r\n|

Re: JDK-8080990: libdt_socket/socket_md.c(202) : warning C4996: 'gethostbyname': Use getaddrinfo() or GetAddrInfoW()

First pass over the code I disabled the compilation flag and then did quick substitution for the easier functions. I commented out the WSASendDisconnect calls so I could see what tests would fail if the function was just removed. I have a replacement now that uses "shutdown(fd,SD_SEND)", but I sti

RFR: JDK-8031445: Attach on windows can fail with java.io.IOException: All pipe instances are busy

The IOException that is observed when creating a new named pipe when the pipe already exists and is in use, recommends to retry the operation later. Since we are already using a random number to generate a unique pipe name, it makes sense to simply retry the operation with a new pipe name. Here i

Re: JDK-8080990: libdt_socket/socket_md.c(202) : warning C4996: 'gethostbyname': Use getaddrinfo() or GetAddrInfoW()

On 2/7/18 12:31 PM, Chris Hegarty wrote: Gary, http://cr.openjdk.java.net/%7Egadams/8080990/webrev.02/ I think the replacement of WSASendDisconnect with shutdown(SD_SEND) should be fine. I do note that there is another usage of WSASendDisconnect in java.base/windows/native/libnet/net_util_md.c

Re: JDK-8080990: libdt_socket/socket_md.c(202) : warning C4996: 'gethostbyname': Use getaddrinfo() or GetAddrInfoW()

On 2/7/18 12:48 PM, Alan Bateman wrote: On 07/02/2018 17:31, Chris Hegarty wrote: Gary, http://cr.openjdk.java.net/%7Egadams/8080990/webrev.02/ I think the replacement of WSASendDisconnect with shutdown(SD_SEND) should be fine. I do note that there is another usage of WSASendDisconnect in jav

Re: RFR: JDK-8031445: Attach on windows can fail with java.io.IOException: All pipe instances are busy

On 2/7/18 3:19 PM, gary.ad...@oracle.com wrote: Hi Gary, I don't think you intended to include the ProblemList.txt changes in your webrev. You are right. I was also looking at JDK-8057732 in the same workspace. I believe there may have been a windows-x86 issue that may no longer be an

Re: JDK-8080990: libdt_socket/socket_md.c(202) : warning C4996: 'gethostbyname': Use getaddrinfo() or GetAddrInfoW()

On 2/7/18 12:55 PM, gary.ad...@oracle.com wrote: On 2/7/18 12:31 PM, Chris Hegarty wrote: Gary, http://cr.openjdk.java.net/%7Egadams/8080990/webrev.02/ I think the replacement of WSASendDisconnect with shutdown(SD_SEND) should be fine. I do note that there is another usage of

Re: JDK-8080990: libdt_socket/socket_md.c(202) : warning C4996: 'gethostbyname': Use getaddrinfo() or GetAddrInfoW()

A fresh webrev rebased with latest jdk/jdk repos:  http://cr.openjdk.java.net/~gadams/8080990/webrev.03/index.html If there are no more comments, I'll check in locally with these reviewers   clanger,chegar,erikj and cut patches on Thurs AM. On 2/5/18 2:15 PM, Gary Adams wrote: One more to fix

RFR: JDK-8169718: nsk/jdb/locals/locals002: ERROR: Cannot find boolVar with expected value: false

/locals002: ERROR: Cannot find boolVar with expected value: false Date: Fri, 25 May 2018 11:35:10 -0400 From: Gary Adams Reply-To: gary.ad...@oracle.com The jdb tests use stdin to send commands to a jdb process and parses the stdout to determine if a command was successful and

Re: RFR: JDK-8169718: nsk/jdb/locals/locals002: ERROR: Cannot find boolVar with expected value: false

t was the reason earlier I was looking at changing the tests to look for specific prompts before continuing to the next command. \gra thanks, Chris On 5/26/18 3:50 AM, gary.ad...@oracle.com wrote: This is a review request for a previously closed test bug. The test was recently moved to the open

Re: RFR: JDK-8205508: hotspot/jtreg/vmTestbase/nsk/jdb/exclude/exclude001/exclude001.java fails with Prompt is not received during 300200 milliseconds.

I'll need a sponsor for the attached patch. It probably should wait for the rdp repos to be forked. I'll file two followup bugs based on the discussions.     - one to continue investigation of why the exclude001 test takes so long     - one to improve the vmTestbase/nsk tests setting of the jtre

Re: RFR: JDK-8206013: vmTestbase/nsk tests should have /timeout configured

We know that the default jtreg timeout is 2 minutes and typically runs with a timeoutfactor of 4 or 10. So the harness "safety net" is 8 to 20 minutes from jtreg. It does appear that most of the vmTestbase tests use a 5 minute waittime. I have seen waittime used in different ways. The one we saw

Re: RFR JDK-8170089: nsk/jdi/EventSet/resume/resume008: ERROR: suspendCounts don't match for : Common-Cleaner

On 7/18/18 4:47 PM, Chris Plummer wrote: Hi Gary Ok, so shouldRunAfterBreakpoint() is the code that does the eventHandler.wait(), so it gets the eventHandler.notifyAll() notification from the BreakpointEvent handler. And as a side note, I see now that resumption of execution after the break

Re: RFR JDK-8170089: nsk/jdi/EventSet/resume/resume008: ERROR: suspendCounts don't match for : Common-Cleaner

During some longer testing runs I noticed similar failures for resume002, resume003 and resume006. I'll spend a few more cycles to see if a more general purpose solution could be shared across these tests. On 7/24/18 7:46 PM, Chris Plummer wrote: Hi Gary, It looks like that should work fine. t

Re: RFR: JDK-8177763: Getting an hprof dump via jcmd could benefit from stronger option checking

On 8/29/18 3:12 PM, Chris Plummer wrote: On 8/29/18 11:57 AM, Gary Adams wrote: Here are the items I'd like to discuss.    1. The current help doc only mention    as a positional argument.    The original bug was posted with an expectation     that should be accepted.    Do we

Re: Ping: RFR JDK-8210725: com/sun/jdi/RedefineClearBreakpoint.java fails with waitForPrompt timed out after 60 seconds

I have no further comments/questions. On 9/20/18 11:52 AM, JC Beyler wrote: Hi Alex, Looks good to me still :) Jc On Wed, Sep 19, 2018 at 5:21 PM Alex Menkov > wrote: Hi all, Ping. The bug has been labeled "timewaster" as it caused failures quite

Re: RFR 8163083: SocketListeningConnector does not allow invocations with port 0

Looks good to me. For the javadoc 72 * 73 * If arguments contains addressing information. and 74 * only one connection will be accepted, the {@link #accept accept} method 75 * can be called immediately without calling this method. 76 * 77 * If the addressing

RFR: JDK-8169718: nsk/jdb/locals/locals002: ERROR: Cannot find boolVar with expected value: false

This is a very old bug that started off as a closed test, but should have an open review before it finally gets pushed. Many other jdb bugs will be closed as duplicates as a result of this change. The problem shows up as a corrupted log when running the jdb tests. The tests send commands to a j

Re: RFR: JDK-8210337: runtime/NMT/VirtualAllocTestType.java failed on RuntimeException missing from stdout/stderr

The problem reproduced pretty quickly. I added a call to checkPermission and revealed the "file not found" from the stat call when the IOException was detected. There has been some flakiness from the Solaris test machines today, so I'll continue with the testing a bit longer. On 10/2/18 3:12 PM,

Re: RFR: JDK-8210337: runtime/NMT/VirtualAllocTestType.java failed on RuntimeException missing from stdout/stderr

has indeed created the file, but it is not immediately visible to the attacher process. Chris On 10/2/18 12:27 PM, gary.ad...@oracle.com wrote: The problem reproduced pretty quickly. I added a call to checkPermission and revealed the "file not found" from the stat call when the IOException