Re: 8220175: serviceability/dcmd/framework/VMVersionTest.java fails with a timeout

Any chance this will also fix JDK-8226367 ? On 6/20/19, 10:39 PM, Chris Plummer wrote: Thanks for looking into this. Chris On 6/20/19 6:42 PM, Daniil Titov wrote: Thank you, Chris and Serguei, for reviewing this change. I did more testing with a test program on Linux that repeats

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

, Gary Adams wrote: That would be consistent with the windows detach() synchronization. Updated patch is attached. On 6/19/19, 8:14 AM, Langer, Christoph wrote: Hi Gary, looks good overall. I however think the block should also be synchronized to avoid issues when multiple threads attempt

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

. Cheers Christoph -Original Message- From: Gary Adams Sent: Mittwoch, 19. Juni 2019 13:59 To: Langer, Christoph Cc: OpenJDK Serviceability; Schmelter, Ralf Subject: Re: RFR: JDK-8224642: Test sun/tools/jcmd/TestJcmdSanity.java fails: Bad file descriptor I think everyone is in agreement now

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

w InputStreamReader(in, "UTF-8"); // read to EOF and just print output char c[] = new char[256]; int n; On 6/17/19 3:23 PM, Gary Adams wrote: https://bugs.openjdk.java.net/browse/JDK-8224642 I may have a handle on what is going wrong with

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

https://bugs.openjdk.java.net/browse/JDK-8224642 I may have a handle on what is going wrong with the TestJcmdSanity test and the bad file descriptor. A change made in April 2019 placed the input stream and reader within the same try with resources block. This has the effect of calling the

Re: [13] RFR: JDK-8225682: Reference to JNI spec on java.sun.com

And the copyright. Looks good to me. On 6/14/19, 2:08 PM, Alex Menkov wrote: Hi all, Please review small fix for "Java Debug Wire Protocol" page. The change fixes the link and typo ("Inteface" -> "Interface"). jira: https://bugs.openjdk.java.net/browse/JDK-8225682 webrev:

Re: RFR: 8206074: nsk/jdi/EventRequestManager/createStepRequest/crstepreq001/TestDescription.java is timing out

This fix looks good to me. We've plugged a number of edge cases in the tests where the timing of debuggee and debugger processes was not guaranteed during shutdown of the test. The only improvement we could add here is to test if the vm is suspended, but an extra resume does no harm to ensure

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

+1 On 5/30/19, 12:39 PM, Alex Menkov wrote: Looks good. --alex On 05/29/2019 19:32, serguei.spit...@oracle.com wrote: Thanks, Gary! I've fixed the copyright year in the test and split the updated lines. Also found some inconsistent use of cached local variables and fixed it. The webrev

Re: RFR: JDK-8218701: jdb tests failed with AGENT_ERROR_INVALID_THREAD

I have not tracked down the specific root cause of this failure, yet. It appears that the suspend is being attempted *before* the thread has been recorded in *threadControl*. Adding diagnostic messages is tricky because it changes the timing. Here's a minimal probe to track threadControl

Fwd: Re: RFR: JDK-8223416: Exclude javax/management/monitor/DerivedGaugeMonitorTest.java until JDK-8042211 is fixed.

...@oracle.com, Internal Serviceability Gary, Thumbs up! But... The test is open so problem listing the test should also be open. The bug is closed because the description contains an internal URL. Dan On 5/7/19 1:56 PM, Gary Adams wrote: Trivial update to ProblemList test while underlying fix

Re: 8222667: vmTestbase/nsk/jdi/ThreadStartRequest/addThreadFilter/addthreadfilter002/TestDescription.java failed with "event IS NOT a breakpoint"

what the test checks (that calling addThreadFilter() on enabled thread start request throws InvalidRequestStateException. Webrev: http://cr.openjdk.java.net/~dtitov/8222667/webrev.02 Bug: https://bugs.openjdk.java.net/browse/JDK-8222667 Thanks! --Danill On 5/2/19, 4:56 AM, "Gary Adams&qu

Re: RFR: 8222667: vmTestbase/nsk/jdi/ThreadStartRequest/addThreadFilter/addthreadfilter002/TestDescription.java failed with "event IS NOT a breakpoint"

It would be good to include a comment that the thread start is being allowed because of graal. Now that we have a series of graal specific alterations in the tests, it might be useful to provide some reusable filters. $.02 On 5/1/19, 9:07 PM, Daniil Titov wrote: Please review the change that

Re: RFR 8223065: Add jcmd to get the listen address of the debugger

In diagnosticCommand.cpp you'll want to use "res != 0" on lines 1084 and 1086 to avoid compiler warnings about ambiguous conversions to boolean. 1082 // The result should be a byte array or null 1083 typeArrayOop res = (typeArrayOop) result.get_jobject(); 1084 assert(!res ||

Re: RFR (S) 8222529: sun.jdwp.listenerAddress agent property uses wrong encoding

It'd be good to have someone on build-dev review this change. On 4/26/19, 3:36 AM, Langer, Christoph wrote: Hi Alex, for other platforms (toolchains), except Windows, -ljava is part of BASIC_JDKLIB_LIBS -> $(JDKLIB_LIBS), see here:

Re: RFR (trivial): 8222970: Update ProblemList for vmTestbase/nsk/jdb/eval/eval001/eval001.java

Looks OK to me. On 4/25/19, 4:36 AM, David Holmes wrote: Bug: https://bugs.openjdk.java.net/browse/JDK-8222970 vmTestbase/nsk/jdb/eval/eval001/eval001.java is ProblemListed under JDK-8221503 which is now closed as a duplicate of JDK-8212117. So ProblemList.txt needs updating. Thanks, David

Re: RFR: JDK-8222741: jdi/EventQueue/remove/remove004 fails due to VMDisconnectedException

s, Chris On 4/19/19 10:06 AM, Gary Adams wrote: Prevent the debuggee from exiting too quickly by holding it at the breakpoint until the end of processing flag has been read by the main thread from the debugger process. Webrev: http://cr.openjdk.java.net/~gadams/8222741/webr

RFR: JDK-8222741: jdi/EventQueue/remove/remove004 fails due to VMDisconnectedException

Prevent the debuggee from exiting too quickly by holding it at the breakpoint until the end of processing flag has been read by the main thread from the debugger process. Webrev: http://cr.openjdk.java.net/~gadams/8222741/webrev/ Issue: https://bugs.openjdk.java.net/browse/JDK-8222741

Re: JDK-8177064: jcmd help command should not require the process identification

On 4/11/19, 8:16 PM, David Holmes wrote: Hi Gary, On 12/04/2019 4:24 am, Gary Adams wrote: Two years ago a request was made to allow jcmd help to be interpretted as a request for help from the current jcmd process rather than requiring a separate target process to be involved. Some

JDK-8177064: jcmd help command should not require the process identification

Two years ago a request was made to allow jcmd help to be interpretted as a request for help from the current jcmd process rather than requiring a separate target process to be involved. Some attempts were made to close the issue, because the command was not documented to work that way. It

Re: RFR: JDK-8203364: Some serviceability/sa/ tests intermittently fail with java.io.IOException: LingeredApp terminated with non-zero exit code 3

I need a second reviewer for this minor update. On 4/2/19, 2:18 PM, Chris Plummer wrote: On 4/2/19 11:11 AM, Gary Adams wrote: The test exits with 3 for the general Exception. I added 4 just to distinguish the return. I see 7 used earlier when the lockfile is not initialized. I could add

Re: RFR: JDK-8203364: Some serviceability/sa/ tests intermittently fail with java.io.IOException: LingeredApp terminated with non-zero exit code 3

Gary, I see various System.exit() calls with varying exit status. Is there some place that documents them? What is 4? Any reason not to print the exception before doing the System.exit(4)? thanks, Chris On 4/2/19 4:50 AM, Gary Adams wrote: This proposed change allows a wider range

RFR: JDK-8203364: Some serviceability/sa/ tests intermittently fail with java.io.IOException: LingeredApp terminated with non-zero exit code 3

This proposed change allows a wider range of IOExceptions to be observed when a LingeredApp is being shutdown. It may not be just a NoSuchFileException. Botton line - if the lock file doesn't exist at the time the IOException is observed then the main application is terminating the test

Re: LingeredApp termination sequence

n instance of NoSuchFileException or the lockfile was deleted by driver. -Dmitry On 29.03.2019 20:12, Gary Adams wrote: While running some bulk testing on jdk/sun/tools I've come across some errors reported from the termination sequence for LingeredApp debuggee process. The main process creates a locking f

RFR: JDK-8221694: jstatLineCounts1 needs to be NaN resilient

With additional testing of jdk/sun/tools The problem seen previously with lineCounts3 and lineCounts4 has begun to appear in lineCounts1. To complete the set this changset will also invlude the same fix for lineCounts2. e.g. allow floating point or NaN dash ("-") in the metaspace column

LingeredApp termination sequence

While running some bulk testing on jdk/sun/tools I've come across some errors reported from the termination sequence for LingeredApp debuggee process. The main process creates a locking file, which the LingeredApp sits in a loop updating the file modification date. When the main test completes

Re: RFR: JDK-8184770: JDWP support for IPv6

Is there any documentation that needs to be updated along with the impl changes? Would it make sense to support the preference properties? java.net.preferIPv4Stack java.net.preferIPv6Addresses Will the previous jdwp tests run with IPv6 or just the new additions? Should probably have

Re: RFR: 8218727: vmTestbase/nsk/jvmti/scenarios/events/EM04/em04t001/TestDescription.java crash in native library

Looks OK to me. On 3/27/19, 3:59 AM, serguei.spit...@oracle.com wrote: Hi Daniil, The fix looks good. Thanks, Serguei On 3/26/19 20:32, Daniil Titov wrote: Please review the change that fixes the test when running with Graal on. The problem here is the lack of synchronization when

JDK-8207347: HeapDumpAllTest.java fails intermittently

I'll try one more time to reproduce the failure running the serviceability/dcmd tests. If there are no failures, I plan to close the issue similar to what was done for JDK-8217220 runtime/NMT/MallocStressTest.java: target process doesn't

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

/8/19 9:41 AM, Gary Adams wrote: On 3/8/19, 12:10 PM, Chris Plummer wrote: You can remove the quarantine and exclude keywords. I think that's appropriate if the test is off the problemlist and working. It was just nonconcurrent removal that I was against. Done As for the resexhausted001 f

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

Here's an updated webrev that includes the change to bind to the stub. The jstatd tests continue to pass after this change. Webrev: http://cr.openjdk.java.net/~gadams/8203026/webrev.01/ It would be good to have a second reviewer from the serviceability team. Longer term it would be good to

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

Agreed. Unless a test is specifically testing the functionality of VirtualMachine.list() it should not be used for locating a pid, which is easily provided from the ProcessBuilder after the process is started. Reducing the environmental interference of scanning all running java processes is

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

, and also know little about RMI, but after reading the bug I can't help but think that your fix might just be hiding a bug else (like in RMI). For example, should UnicastRemoteObject.exportObject() be keeping the remoteHost object live? thanks, Chris On 3/21/19 11:47 AM, Gary Adams wrote

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

    rvm = new RemoteVmImpl((BufferedMonitoredVm)mvm); stub = (RemoteVm) UnicastRemoteObject.exportObject(rvm, 0); } catch (URISyntaxException e) { On 3/20/19, 8:26 AM, Gary Adams wrote: I think I have found the source of the dash.  sun/tools/jstat/RowC

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

ents is " + CGC + ", but CGCT is 0"); } I'm not sure if any of this is related to what you are seeing. Chris On 3/19/19 11:39 AM, Gary Adams wrote: A quick follow up on the jstat test failures. On the failed runs the output looks like this :

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

AM, Gary Adams wrote: After 1000 testruns on {solaris,linux,windows,macosx} debug builds running test/jdk/sun/tools test/jdk/com/sun/tools/attach with this change, no failures were observed in TestJps or TempDirTest. diff --git a/test/jdk/TEST.ROOT b/test/jdk/TEST.ROOT --- a/test/jdk

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

After 1000 testruns on {solaris,linux,windows,macosx} debug builds running test/jdk/sun/tools test/jdk/com/sun/tools/attach with this change, no failures were observed in TestJps or TempDirTest. diff --git a/test/jdk/TEST.ROOT b/test/jdk/TEST.ROOT --- a/test/jdk/TEST.ROOT +++

RFR: JDK-8220678: unquarantine nsk/jdi/ThreadReference/setEnabled/setenabled003

This trivial changeset will restore setenabled003 testing to jdk 13 where the test does not appear to be failing. The original bug JDK-8066993 will be left open in case sustaining team needs to apply changes in older releases. diff --git a/test/hotspot/jtreg/ProblemList.txt

Re: RFR: JDK-8218166: [Graal] com/sun/jdi/SimulResumerTest.java failure

m.out.println("bkpts = " + bkpts + ", iters = " + iters); try { Thread.sleep(waitTime); check(debuggeeThread1); On 3/7/19, 8:19 AM, Gary Adams wrote: While trying to reproduce the timeou

Re: JDK-8218166: [Graal] com/sun/jdi/SimulResumerTest.java failure

to catching and ignoring ObjectCollectedException could be just calling disableCollection() on these two thread references when a breakpoint handle is called (lines 130 and 135). Thanks! Best regards, Daniil On 3/12/19, 11:05 AM, "serviceability-dev on behalf of Gary Adams&qu

Re: RFR: JDK-8218166: [Graal] com/sun/jdi/SimulResumerTest.java failure

Still need 2 more reviewers ... On 3/7/19, 9:45 AM, Daniel D. Daugherty wrote: Gary, Since the 'graal' label was recently removed, I also removed "[Graal]" from the bug synopsis. Please make sure you update your commit mesg. On 3/7/19 8:19 AM, Gary Adams wrote: While trying to

RFR: JDK-8220257: fix headings in java.instrument

Need one reviewer for this trivial correction . After pushing the GPL header update, the h3 to h2 tags will be updated. The copyright will be changed with the headings, so I'll push that change first. JDK-8220474: Incorrect GPL header in

RFR: JDK-8220474: Incorrect GPL header in src/java.instrument/share/classes/java/lang/instrument/package-info.java

Need one reviewer for this trivial correction . Issue: https://bugs.openjdk.java.net/browse/JDK-8220474 diff --git a/src/java.instrument/share/classes/java/lang/instrument/package-info.java b/src/java.instrument/share/classes/java/lang/instrument/package-info.java ---

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

These attach tests interact with all running Java processes. From the logs of the failing tests you can see a few infrastructure Java processes and a number of other Java attaching tests including jinfo, jmap, jstat, etc. JDK-8220295: sun/tools/jps/TestJps.java still timing out JDK-8220242:

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

y new flag or change in behaviour. But to be blunt I don't like where this is going and the cure seems far worse than the disease. David On 16/02/2019 4:39 am, Gary Adams wrote: It isn't pretty, but it's functional : "-f to force communication. ... Revised webrev: http://cr.openjdk.j

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

, or attempt to run the test even though the @ignore directive is there. thanks, Chris On 3/8/19 5:07 AM, Gary Adams wrote: I'll revert the comments that were left in during the tonga conversion. I did come across an interesting test failure in resexhausted001 which had an @ignore 7013634

RFR: JDK-8013728: nsk/jdi/BScenarios/hotswap/tc10x001 Unrecognized Windows Sockets error: 0: recv failed

I've been able to reproduce the socket teardown failure in tc10x001. It appears that the debugee sends it's final output and then exits. If the debugee exits while the debugger is receiving the final output, it can result in a socket error. This proposed fix forces the debugee to wait until the

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

od. thanks, Chris On 3/7/19 10:57 AM, Gary Adams wrote: This proposed fix will restore the ResourceExhausted tests. Test 3 and 4 were on the ProblemList because of the potential path issues in finding the correct classes. This change searches the test.class.path for the appropriate vmTest

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

-03-07 at 13:57 -0500, Gary Adams wrote: This proposed fix will restore the ResourceExhausted tests. Test 3 and 4 were on the ProblemList because of the potential path issues in finding the correct classes. This change searches the test.class.path for the appropriate vmTestbase classes rather than

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

This proposed fix will restore the ResourceExhausted tests. Test 3 and 4 were on the ProblemList because of the potential path issues in finding the correct classes. This change searches the test.class.path for the appropriate vmTestbase classes rather than using incorrect settings on the

RFR: JDK-8218166: [Graal] com/sun/jdi/SimulResumerTest.java failure

While trying to reproduce the timeout reported in JDK-8000669: com/sun/jdi/SimulResumerTest.java times out I was unable to reproduce the timeout failure, but I did occasionally see the ObjectCollectedException. The output from the test is very verbose and may be the source of the occasional

Re: RFR: 8218464: vmTestbase/nsk/jdi/VirtualMachine/allThreads/allthreads001/TestDescription.java failed

Looks OK to me. On 3/5/19, 5:47 PM, serguei.spit...@oracle.com wrote: Hi Daniil, The fix looks good. Thanks, Serguei On 3/5/19 1:59 PM, Daniil Titov wrote: Please review a fix for this test that intermittently fails with Graal on. The problem here is that the test does two consequent

RFR: JDK-8201252: unquarantine nsk/jdi/ThreadReference/resume/resume001

After 1000's of test runs with the resume001 test off the ProblemList, no new sightings have been observed. I intend to use the JDK-8201252 issue to restore the test. JDK-8072701 will be updated and left for sustaining, if the fix needs to be applied to older releases. diff --git

Re: RFR(XS) 8220030: JdbStopThreadidTest.java failed due to "Unexpected IO error while writing command 'quit' to jdb stdin stream"

This looks OK to me. If a specific return code is expected, then the test should wait until it gets the response it needs. If a specific return is not required, the test should be lenient about what information is required for the test to complete. On 3/4/19, 10:41 PM, Chris Plummer wrote:

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

er side. The code is poorly structured, it is hard to understand what it is doing. > - resumed main thread after breakpoint enabled and thread2 double resume Could you, please, explain more how does this help and why timeouts are intermittent? Thanks, Serguei On 2/22/19 11:52 AM, Gary

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

, Alex Menkov wrote: +1 But could you please remove old "pipe.println("docontinue")" statement instead of commenting it out (no new webrev is required) --alex On 02/20/2019 09:58, Chris Plummer wrote: Looks good. Chris On 2/20/19 7:57 AM, Gary Adams wrote: The is

JDK-8149460: jmap give unrelated error message if non java process id is specified in the command.

I'd like to close this bug as "cannot reproduce". The diagnostic output that suggested to use the "-F" option was removed when the tmtools were decoupled from the serviceability agent. See JDK-8155091 (May 2016). Issue: https://bugs.openjdk.java.net/browse/JDK-8149460

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

The issuspended002 has been on the ProblemList since the tests were moved to the open repos. The proposed changeset applies the same fix that was used in issuspended001. The current test fails when the debuggee replies with the "docontinue" response, while it is still holding a lock in a

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

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 first pass I went after cleaning up the issuspend002a messages, because I'm

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

debuggee launched"); ./VoidValue/hashCode/hashcode001/hashcode001.java:207: log2("setvalue003a debuggee launched"); And I noticed a very large number of tests that only have: log2("debuggee launched"); But there are so many that if you are to fix them, it

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

A log message should have been parameterized with the debuggeeName. Issue: https://bugs.openjdk.java.net/browse/JDK-8219388 Webrev: http://cr.openjdk.java.net/~gadams/8219388/webrev.00/

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

a cmd line option parsing detail. Dan On 2/15/19 11:37 AM, Gary Adams wrote: Here's a quick dirty "-F" that gets past the "-XX:-UsePerfData" setting for jcmd. Need to follow up on docs and usage for the other commands. Is this the direction you were thinking? diff --

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

r vmd: l) { + if (vmd.id().equals(pid)) { + found = true; + break; + } + } + return found; + } +} On 2/15/19, 10:24 AM, Daniel D. Daugherty wrote: On 2/15/19 8:44 AM, Gary Adams wrote: Confirmed -XX:-UsePerfData prevents v

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

enfels.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-java pid is specified in the command line On a linux system with 1 Java process and 50

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

pid. Thank god for the command name argument option on jcmd, which I now use mostly. We also had a customer which tried to find all VMs on his machine by attempting to attach with jcmd to every process, killing them left and right :) ... Thomas Thanks, David On 15/02/2019 5:12 am,

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

be necessary to include a override of the pid check. On 2/15/19, 7:29 AM, Gary Adams wrote: I'll get some measurements on some local systems so we have a specific idea about the overhead of the pid check. I imagine in most production environments the /tmp tmpfs is memory only set of checks. One

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

tried to find all VMs on his machine by attempting to attach with jcmd to every process, killing them left and right :) ... Thomas Thanks, David On 15/02/2019 5:12 am, Gary Adams wrote: > The following commands present a similar kill process behavior: >

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

also have this issue? thanks, Chris On 2/14/19 8:35 AM, Gary Adams wrote: There is an old reported problem that using jmap on a process that is not running Java could cause the process to terminate. This is due to the SIGQUIT used when attaching to the process. It is a fairly simple

RFR: JDK-8219002: Some comments and error messages refer to VMDisconnectException

Trivial cleanup of a misspelled exception : VMDisconnectException VMDisconnectedException Webrev: http://cr.openjdk.java.net/~gadams/8219002/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8219002

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

There is an old reported problem that using jmap on a process that is not running Java could cause the process to terminate. This is due to the SIGQUIT used when attaching to the process. It is a fairly simple operation to validate that the pid matches one of the known running Java processes

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

The setenabled003 test has been on the ProblemList since it was first moved to the open repos. After 1000 test runs on {solaris, macosx, windows, linux} for the test/hotspot/jtreg/vmTestbase/nsk/jdi/EventRequest/setEnabled tests, the problem does not currently reproduce. My recommendation is

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

On 2/12/19, 7:14 AM, David Holmes wrote: On 12/02/2019 10:11 pm, Gary Adams wrote: Yes, see the revised webrev, we do have to guard against multiple calls to dispose, e.g. catch and ignore VMDisconnectException. We don't need to guard against a null vm. That would only exist if the vm was never

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

Yes, see the revised webrev, we do have to guard against multiple calls to dispose, e.g. catch and ignore VMDisconnectException. We don't need to guard against a null vm. That would only exist if the vm was never initialized and we were shutting down. There is a race condition between the

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

Have to guard against multiple calls to dispose. Revised webrev: http://cr.openjdk.java.net/~gadams/8218754/webrev.00/ Issue: https://bugs.openjdk.java.net/browse/JDK-8218754 On 2/12/19, 5:08 AM, gary.ad...@oracle.com wrote: The recent change to JDK-8068225 changed the order of operations

Re: RFR: JDK-8068225: nsk/jdi/EventQueue/remove_l/remove_l005 intermittently times out

if the test run is good. Thanks, Serguei On 2/8/19 05:25, Gary Adams wrote: The intermittent failures for remove_l005 appears to be due to a timing issue in the shutdown handling after the test has completed. The debugger has sent a "quit" command, but the debugee has not completed

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

On 2/5/19, 4:59 PM, David Holmes wrote: On 5/02/2019 10:17 pm, Gary Adams wrote: On 2/4/19, 8:04 PM, David Holmes wrote: Hi Gary, On 5/02/2019 12:01 am, Gary Adams wrote: Two of the redefine classes tests (021, 023) have been on the ProblemList since they were first brought into the open

RFR: JDK-8068225: nsk/jdi/EventQueue/remove_l/remove_l005 intermittently times out

The intermittent failures for remove_l005 appears to be due to a timing issue in the shutdown handling after the test has completed. The debugger has sent a "quit" command, but the debugee has not completed processing the command and exited as expected. This proposed change modifies the

Re: RFR: JDK-8068225: nsk/jdi/EventQueue/remove_l/remove_l005 intermittently times out

On 2/6/19, 1:16 PM, Chris Plummer wrote: Does it timeout in waitFor()? Chris On 2/6/19 10:01 AM, Gary Adams wrote: So far the only test that has an issue with the change in waitFor order is nsk/jdi/VirtualMachine/canBeModified, which does not appear to synchronize with the debuggee. On 2/6

Re: RFR: JDK-8068225: nsk/jdi/EventQueue/remove_l/remove_l005 intermittently times out

of the debugeee? Won't waitFor() wait forever in that case? I think by having the vm.dispose() first, you avoid that issue. Chris On 2/6/19 8:04 AM, Gary Adams wrote: Testing an alternate fix that will wait for the debugee process to terminate after processing the "quit" command be

Re: RFR: JDK-8068225: nsk/jdi/EventQueue/remove_l/remove_l005 intermittently times out

try { vm.dispose(); @@ -564,7 +565,7 @@ } vm = null; } -return waitFor(); +return status; } On 2/6/19, 8:14 AM, Gary Adams wrote: Just a quick update on the failure on shutdown ... I've come across a couple of o

Re: RFR: JDK-8068225: nsk/jdi/EventQueue/remove_l/remove_l005 intermittently times out

display(""); } display(""); display("="); display("TEST FINISHES\n"); brkpReq.disable(); debugee.resume(); debugee.quit(); } Thanks, Serguei On 2/1/19 10:00, Gary Adams wrote: When

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

On 2/4/19, 8:04 PM, David Holmes wrote: Hi Gary, On 5/02/2019 12:01 am, Gary Adams wrote: Two of the redefine classes tests (021, 023) have been on the ProblemList since they were first brought into the open repos. Both tests made an incorrect assumption about the access modifiers in class

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

Two of the redefine classes tests (021, 023) have been on the ProblemList since they were first brought into the open repos. Both tests made an incorrect assumption about the access modifiers in class files. There is a single bit in the binary class file that defines if an interface is public

RFR: JDK-8068225: nsk/jdi/EventQueue/remove_l/remove_l005 intermittently times out

When the remove_l005 runs to completion, it never signals the debuggee that all iterations have completed. Issue: https://bugs.openjdk.java.net/browse/JDK-8068225 diff --git a/test/hotspot/jtreg/ProblemList.txt b/test/hotspot/jtreg/ProblemList.txt --- a/test/hotspot/jtreg/ProblemList.txt

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

threads are suspended and act accordingly. Also, what happens if after attaching again you issue a "cont" command? Chris On 1/29/19 9:55 AM, Gary Adams wrote: As far as I can tell, the quit and exit commands are only handled locally on the debugger side of the connection. There is no packet

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

sumed at that point, and shouldn't that result in the command loop being unblocked? thanks, Chris On 1/29/19 8:09 AM, Gary Adams wrote: Significant protections are put in place to protect the commandLoop from multiple events that that have a suspend-all policy. The commandLoop uses a special bloc

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

Significant protections are put in place to protect the commandLoop from multiple events that that have a suspend-all policy. The commandLoop uses a special block variable to ensure only a VirtualMachine or ThreadReference call to resume() will unblock the commandLoop. See

Re: RFR JDK-8216386: vmTestbase/nsk/jvmti/PopFrame/popframe005/TestDescription.java fails

I like the fact that test.timeout.factor is applied as a multiplier. It's not clear why an upper limit had to be added. Is that 50 or 5 seconds? 148 objWaiterThr1.join(Math.min(WAIT_TIME, 5)); Why are the other wait times not limited? 136

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

ossibility is to use the newer Windows MoveFile function... On 1/16/19, 11:24 AM, Daniel D. Daugherty wrote: > rename A to A1 I believe the virus scanner will also mess with file renames on Win* so you may see intermittent failures for this operation. Dan On 1/11/19 11:01 AM, Gary Adams wr

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

am, Gary Adams wrote: Here's a webrev for review purposes. No failures after ~1000 testruns. Webrev: http://cr.openjdk.java.net/~gadams/8158066/webrev.00/ Issue: https://bugs.openjdk.java.net/browse/JDK-8158066 On 1/11/19, 11:01 AM, Gary Adams wrote: I've been reading recently

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

Here's a webrev for review purposes. No failures after ~1000 testruns. Webrev: http://cr.openjdk.java.net/~gadams/8158066/webrev.00/ Issue: https://bugs.openjdk.java.net/browse/JDK-8158066 On 1/11/19, 11:01 AM, Gary Adams wrote: I've been reading recently that Windows delete file

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

I've been reading recently that Windows delete file operations can be delayed, if there are open handles against the file. Others have reported virus checkers or other indexing programs may hold a handle on a file preventing the deletion being completed. The basic logic in InstallSDE is A + B

Re: RFR: JDK-8213001: vmTestbase/nsk/jvmti/ThreadStart/threadstart002/TestDescription.java debug agent times out

I could use another reviewer, or an ok to push as a trivial change. On 1/8/19, 11:32 AM, Gary Adams wrote: A number failures of threadstart002 have been reported on windows-x64-debug builds. This configuration has a jtreg timeout factor assigned so the test can run 10x slower

RFR: JDK-8213001: vmTestbase/nsk/jvmti/ThreadStart/threadstart002/TestDescription.java debug agent times out

A number failures of threadstart002 have been reported on windows-x64-debug builds. This configuration has a jtreg timeout factor assigned so the test can run 10x slower and not experience a timeout. Unfortunately, these older vmTestbase tests were not fully integrated with the jtreg

RFR: JDK-8216059: nsk_jvmti_parseoptions still has dependency on tilde separator

The test/hotspot/jtreg/vmTestbase/vm/mlvm tests were missed when the parser was updated for JDK-8211343. Those tests use tilde (~) as an option separator. Here's a quick fix to add tilde back as an option separator. Testing is in progress. diff --git

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

I had no further comments. On 1/2/19, 10:47 AM, Lindenmaier, Goetz wrote: Hi Gary, as promised, I'll do a follow up fixing all these. But all the tests you mention are either not configured for aix (@requires linux etc) or are passing currently. So no need for action here. I just want to do

RFR: JDK-8211343: nsk_jvmti_parseoptions should handle multiple suboptions

Here is a first pass at a replacement parser for jvmti test options. Webrev: http://cr.openjdk.java.net/~gadams/8211343/webrev.00/ Issue: https://bugs.openjdk.java.net/browse/JDK-8211343 Testing is in progress. Need to check out more platforms. On local linux testing one jvmti test failed

Re: JDK-8211343: nsk_jvmti_parseoptions should handle multiple suboptions

_len, val_sep, val_len)) { success = NSK_FALSE; break; } opt_end++; opt = opt_end; } On 12/20/18 8:33 AM, Gary Adams wrote: I prototyped with strsep, because strtok is not safe and did not want to deal with the strtok_r versus strtok_s (windows)

Re: JDK-8211343: nsk_jvmti_parseoptions should handle multiple suboptions

, the webrev looks good except perhaps for the use of strsep, which is BSD, instead of strtok, which is C89/C99/Posix. Thanks for doing this! Jc On Thu, Dec 20, 2018 at 5:17 AM Gary Adams <mailto:gary.ad...@oracle.com>> wrote: During some earlier jvmti test debugging, I notic

JDK-8211343: nsk_jvmti_parseoptions should handle multiple suboptions

During some earlier jvmti test debugging, I noticed that it was not possible to add a quick argument to the current tests and rerun the test. e.g. expand "waittime=5" to "waittime=5,verbose". I tracked down the options parsing in jvmti_tools.cpp and saw some comments that only a single option

RFR: JDK-8215571: jdb does not include jdk.* in the default class filter

This should be a trivial update. The default "excludes" filter for jdb should have been updated when the jdk.* packages were first introduced. diff --git a/src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/Env.java b/src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/Env.java

  1   2   3   >