Re: RFR: JDK-8068225: nsk/jdi/EventQueue/remove_l/remove_l005 intermittently times out
I missed a couple of tests in the vm/mlvm area {breakpoint, breakpointInCompiledCode, breakpointOtherStratum}. I filed JDK-8218754 to follow up with those timeouts during debugee exiting. The good news is the problem is easily reproduced in a local linux debug build, so it should be easier to track down. e.g. JDIBreakpointTest has a direct call to debugee.endDebugee(). May need the same fix used for canBeModified, e.g. resume the debugee to let it finish before waiting for an exit status. On 2/8/19, 1:37 PM, serguei.spit...@oracle.com wrote: Hi Gary, I'm Okay with the fix 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 processing the command and exited as expected. This proposed change modifies the Debugee.endDebugee() processing to wait for the debuggee to complete before doing the tear down processing on the debugger side of the connection. This sequencing did expose an issue in the canBeModified test, where the debugee was never resumed after the VMStart event was detected. Resuming the debugee allows it to respond as expected when the direct call to endDebugee is invoked. Testing is still in progress, but it looks like this will resolve a number of tail end intermittent failures. Issue: https://bugs.openjdk.java.net/browse/JDK-8068225 Webrev: http://cr.openjdk.java.net/~gadams/8068225/webrev.00/
Re: RFR: JDK-8068225: nsk/jdi/EventQueue/remove_l/remove_l005 intermittently times out
+1 Chris On 2/8/19 2:26 PM, Jean Christophe Beyler wrote: Hi Gary, Looks good to me too :) Thanks, Jc On Fri, Feb 8, 2019 at 10:40 AM serguei.spit...@oracle.comwrote: Hi Gary, I'm Okay with the fix 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 processing the > command > and exited as expected. > > This proposed change modifies the Debugee.endDebugee() processing to > wait for the debuggee to complete before doing the tear down processing > on the debugger side of the connection. This sequencing did expose > an issue in the canBeModified test, where the debugee was never resumed > after the VMStart event was detected. Resuming the debugee allows it to > respond as expected when the direct call to endDebugee is invoked. > > Testing is still in progress, but it looks like this will resolve a > number of > tail end intermittent failures. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8068225 > Webrev: http://cr.openjdk.java.net/~gadams/8068225/webrev.00/ -- Thanks, Jc
Re: RFR: JDK-8068225: nsk/jdi/EventQueue/remove_l/remove_l005 intermittently times out
Hi Gary, Looks good to me too :) Thanks, Jc On Fri, Feb 8, 2019 at 10:40 AM serguei.spit...@oracle.com < serguei.spit...@oracle.com> wrote: > Hi Gary, > > I'm Okay with the fix 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 processing the > > command > > and exited as expected. > > > > This proposed change modifies the Debugee.endDebugee() processing to > > wait for the debuggee to complete before doing the tear down processing > > on the debugger side of the connection. This sequencing did expose > > an issue in the canBeModified test, where the debugee was never resumed > > after the VMStart event was detected. Resuming the debugee allows it to > > respond as expected when the direct call to endDebugee is invoked. > > > > Testing is still in progress, but it looks like this will resolve a > > number of > > tail end intermittent failures. > > > > Issue: https://bugs.openjdk.java.net/browse/JDK-8068225 > > Webrev: http://cr.openjdk.java.net/~gadams/8068225/webrev.00/ > > -- Thanks, Jc
Re: RFR: JDK-8068225: nsk/jdi/EventQueue/remove_l/remove_l005 intermittently times out
Hi Gary, I'm Okay with the fix 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 processing the command and exited as expected. This proposed change modifies the Debugee.endDebugee() processing to wait for the debuggee to complete before doing the tear down processing on the debugger side of the connection. This sequencing did expose an issue in the canBeModified test, where the debugee was never resumed after the VMStart event was detected. Resuming the debugee allows it to respond as expected when the direct call to endDebugee is invoked. Testing is still in progress, but it looks like this will resolve a number of tail end intermittent failures. Issue: https://bugs.openjdk.java.net/browse/JDK-8068225 Webrev: http://cr.openjdk.java.net/~gadams/8068225/webrev.00/
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 Debugee.endDebugee() processing to wait for the debuggee to complete before doing the tear down processing on the debugger side of the connection. This sequencing did expose an issue in the canBeModified test, where the debugee was never resumed after the VMStart event was detected. Resuming the debugee allows it to respond as expected when the direct call to endDebugee is invoked. Testing is still in progress, but it looks like this will resolve a number of tail end intermittent failures. Issue: https://bugs.openjdk.java.net/browse/JDK-8068225 Webrev: http://cr.openjdk.java.net/~gadams/8068225/webrev.00/
Re: RFR: JDK-8068225: nsk/jdi/EventQueue/remove_l/remove_l005 intermittently times out
Ok. I think the fix is fine then if this is the only test that was problematic. Chris On 2/6/19 11:02 AM, Gary Adams wrote: Yes, the test was hung in waitFor. The debugger process made some calls after the VMStart event was observed, but never resumed the debuggee. Here's a simple change that makes test run to completion cleanly. diff --git a/test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/canBeModified/canbemodified001.java b/test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/canBeModified/canbemodified001.java --- a/test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/canBeModified/canbemodified001.java +++ b/test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/canBeModified/canbemodified001.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2003, 2018, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2003, 2019, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -78,6 +78,7 @@ exitStatus = Consts.TEST_FAILED; e.printStackTrace(); } finally { + debugee.resume(); debugee.endDebugee(); } display("Test finished. exitStatus = " + exitStatus); 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/19, 12:15 PM, Chris Plummer wrote: What happens if endDebugee() is called when the caller is not expecting a clean exit 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 before doing the vm tear down. diff --git a/test/hotspot/jtreg/vmTestbase/nsk/share/jdi/Debugee.java b/test/hotspot/jtreg/vmTestbase/nsk/share/jdi/Debugee.java --- a/test/hotspot/jtreg/vmTestbase/nsk/share/jdi/Debugee.java +++ b/test/hotspot/jtreg/vmTestbase/nsk/share/jdi/Debugee.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2001, 2018, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2001, 2019, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -557,6 +557,7 @@ * exit status code. */ public int endDebugee() { + int status = waitFor(); if (vm != null) { 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 other tests with a similar failure mode. I'm attempting to get some additional diagnostic information from these tests with "-jdi.trace=all", but the diagnostic output may be interfering with the timing. My current investigation is around a possible race condition in the Debgugee.quit() processing. - the "quit" string is sent to the deuggee via the IOpipe - the vm.dispose() is handled from the JDWP communication If the context switching is not quick enough, the debugee may not have read and processed the "quit" command before tear down is handled. From earlier comments in the bug report the debuggee was observed still at the breakpoint, so the resume and the disabling of the breakpoint had not been processed, yet. It might be worth having an "ack" returned when the "quit" is processed in the debugee. ... On 2/1/19, 2:15 PM, serguei.spit...@oracle.com wrote: Hi Gary, The debugee.quit() is to complete the session. It makes this call: sendSignal(SGNL_QUIT); A call to the debugee.quit() is at the end of execTest() method: 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 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 +++ b/test/hotspot/jtreg/ProblemList.txt @@ -163,7 +163,6 @@ vmTestbase/nsk/jdi/EventRequest/setEnabled/setenabled003/TestDescription.java 8066993 generic-all vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses021/TestDescription.java 8065773 generic-all vmTestbase/nsk
Re: RFR: JDK-8068225: nsk/jdi/EventQueue/remove_l/remove_l005 intermittently times out
Yes, the test was hung in waitFor. The debugger process made some calls after the VMStart event was observed, but never resumed the debuggee. Here's a simple change that makes test run to completion cleanly. diff --git a/test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/canBeModified/canbemodified001.java b/test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/canBeModified/canbemodified001.java --- a/test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/canBeModified/canbemodified001.java +++ b/test/hotspot/jtreg/vmTestbase/nsk/jdi/VirtualMachine/canBeModified/canbemodified001.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2003, 2018, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2003, 2019, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -78,6 +78,7 @@ exitStatus = Consts.TEST_FAILED; e.printStackTrace(); } finally { +debugee.resume(); debugee.endDebugee(); } display("Test finished. exitStatus = " + exitStatus); 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/19, 12:15 PM, Chris Plummer wrote: What happens if endDebugee() is called when the caller is not expecting a clean exit 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 before doing the vm tear down. diff --git a/test/hotspot/jtreg/vmTestbase/nsk/share/jdi/Debugee.java b/test/hotspot/jtreg/vmTestbase/nsk/share/jdi/Debugee.java --- a/test/hotspot/jtreg/vmTestbase/nsk/share/jdi/Debugee.java +++ b/test/hotspot/jtreg/vmTestbase/nsk/share/jdi/Debugee.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2001, 2018, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2001, 2019, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -557,6 +557,7 @@ * exit status code. */ public int endDebugee() { +int status = waitFor(); if (vm != null) { 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 other tests with a similar failure mode. I'm attempting to get some additional diagnostic information from these tests with "-jdi.trace=all", but the diagnostic output may be interfering with the timing. My current investigation is around a possible race condition in the Debgugee.quit() processing. - the "quit" string is sent to the deuggee via the IOpipe - the vm.dispose() is handled from the JDWP communication If the context switching is not quick enough, the debugee may not have read and processed the "quit" command before tear down is handled. From earlier comments in the bug report the debuggee was observed still at the breakpoint, so the resume and the disabling of the breakpoint had not been processed, yet. It might be worth having an "ack" returned when the "quit" is processed in the debugee. ... On 2/1/19, 2:15 PM, serguei.spit...@oracle.com wrote: Hi Gary, The debugee.quit() is to complete the session. It makes this call: sendSignal(SGNL_QUIT); A call to the debugee.quit() is at the end of execTest() method: 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 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 +++ b/test/hotspot/jtreg/ProblemList.txt @@ -163,7 +163,6 @@ vmTestbase/nsk/jdi/EventRequest/setEnabled/setenabled003/TestDescription.java 8066993 generic-all vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses021/TestDescription.java 8065773 generic-all vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses023/TestDescription.java 8065773 generic-all -vmTestbase/nsk/jdi/EventQueue/remo
Re: RFR: JDK-8068225: nsk/jdi/EventQueue/remove_l/remove_l005 intermittently times out
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/19, 12:15 PM, Chris Plummer wrote: What happens if endDebugee() is called when the caller is not expecting a clean exit 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 before doing the vm tear down. diff --git a/test/hotspot/jtreg/vmTestbase/nsk/share/jdi/Debugee.java b/test/hotspot/jtreg/vmTestbase/nsk/share/jdi/Debugee.java --- a/test/hotspot/jtreg/vmTestbase/nsk/share/jdi/Debugee.java +++ b/test/hotspot/jtreg/vmTestbase/nsk/share/jdi/Debugee.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2001, 2018, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2001, 2019, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -557,6 +557,7 @@ * exit status code. */ public int endDebugee() { + int status = waitFor(); if (vm != null) { 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 other tests with a similar failure mode. I'm attempting to get some additional diagnostic information from these tests with "-jdi.trace=all", but the diagnostic output may be interfering with the timing. My current investigation is around a possible race condition in the Debgugee.quit() processing. - the "quit" string is sent to the deuggee via the IOpipe - the vm.dispose() is handled from the JDWP communication If the context switching is not quick enough, the debugee may not have read and processed the "quit" command before tear down is handled. From earlier comments in the bug report the debuggee was observed still at the breakpoint, so the resume and the disabling of the breakpoint had not been processed, yet. It might be worth having an "ack" returned when the "quit" is processed in the debugee. ... On 2/1/19, 2:15 PM, serguei.spit...@oracle.com wrote: Hi Gary, The debugee.quit() is to complete the session. It makes this call: sendSignal(SGNL_QUIT); A call to the debugee.quit() is at the end of execTest() method: 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 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 +++ b/test/hotspot/jtreg/ProblemList.txt @@ -163,7 +163,6 @@ vmTestbase/nsk/jdi/EventRequest/setEnabled/setenabled003/TestDescription.java 8066993 generic-all vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses021/TestDescription.java 8065773 generic-all vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses023/TestDescription.java 8065773 generic-all -vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005/TestDescription.java 8068225 generic-all vmTestbase/metaspace/gc/firstGC_10m/TestDescription.java 8208250 generic-all vmTestbase/metaspace/gc/firstGC_50m/TestDescription.java 8208250 generic-all diff --git a/test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005.java b/test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005.java --- a/test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005.java +++ b/test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2002, 2018, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2002, 2019, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -134,6 +134,7 @@ } display(""); } + debugee.sendSignal(SGNL_QUIT); display(""); display("=");
Re: RFR: JDK-8068225: nsk/jdi/EventQueue/remove_l/remove_l005 intermittently times out
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/19, 12:15 PM, Chris Plummer wrote: What happens if endDebugee() is called when the caller is not expecting a clean exit 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 before doing the vm tear down. diff --git a/test/hotspot/jtreg/vmTestbase/nsk/share/jdi/Debugee.java b/test/hotspot/jtreg/vmTestbase/nsk/share/jdi/Debugee.java --- a/test/hotspot/jtreg/vmTestbase/nsk/share/jdi/Debugee.java +++ b/test/hotspot/jtreg/vmTestbase/nsk/share/jdi/Debugee.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2001, 2018, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2001, 2019, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -557,6 +557,7 @@ * exit status code. */ public int endDebugee() { +int status = waitFor(); if (vm != null) { 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 other tests with a similar failure mode. I'm attempting to get some additional diagnostic information from these tests with "-jdi.trace=all", but the diagnostic output may be interfering with the timing. My current investigation is around a possible race condition in the Debgugee.quit() processing. - the "quit" string is sent to the deuggee via the IOpipe - the vm.dispose() is handled from the JDWP communication If the context switching is not quick enough, the debugee may not have read and processed the "quit" command before tear down is handled. From earlier comments in the bug report the debuggee was observed still at the breakpoint, so the resume and the disabling of the breakpoint had not been processed, yet. It might be worth having an "ack" returned when the "quit" is processed in the debugee. ... On 2/1/19, 2:15 PM, serguei.spit...@oracle.com wrote: Hi Gary, The debugee.quit() is to complete the session. It makes this call: sendSignal(SGNL_QUIT); A call to the debugee.quit() is at the end of execTest() method: 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 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 +++ b/test/hotspot/jtreg/ProblemList.txt @@ -163,7 +163,6 @@ vmTestbase/nsk/jdi/EventRequest/setEnabled/setenabled003/TestDescription.java 8066993 generic-all vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses021/TestDescription.java 8065773 generic-all vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses023/TestDescription.java 8065773 generic-all -vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005/TestDescription.java 8068225 generic-all vmTestbase/metaspace/gc/firstGC_10m/TestDescription.java 8208250 generic-all vmTestbase/metaspace/gc/firstGC_50m/TestDescription.java 8208250 generic-all diff --git a/test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005.java b/test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005.java --- a/test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005.java +++ b/test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2002, 2018, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2002, 2019, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -134,6 +134,7 @@ } display(""); } +debugee.sendSignal(SGNL_QUIT); display(""); display("=");
Re: RFR: JDK-8068225: nsk/jdi/EventQueue/remove_l/remove_l005 intermittently times out
What happens if endDebugee() is called when the caller is not expecting a clean exit 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 before doing the vm tear down. diff --git a/test/hotspot/jtreg/vmTestbase/nsk/share/jdi/Debugee.java b/test/hotspot/jtreg/vmTestbase/nsk/share/jdi/Debugee.java --- a/test/hotspot/jtreg/vmTestbase/nsk/share/jdi/Debugee.java +++ b/test/hotspot/jtreg/vmTestbase/nsk/share/jdi/Debugee.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2001, 2018, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2001, 2019, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -557,6 +557,7 @@ * exit status code. */ public int endDebugee() { + int status = waitFor(); if (vm != null) { 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 other tests with a similar failure mode. I'm attempting to get some additional diagnostic information from these tests with "-jdi.trace=all", but the diagnostic output may be interfering with the timing. My current investigation is around a possible race condition in the Debgugee.quit() processing. - the "quit" string is sent to the deuggee via the IOpipe - the vm.dispose() is handled from the JDWP communication If the context switching is not quick enough, the debugee may not have read and processed the "quit" command before tear down is handled. From earlier comments in the bug report the debuggee was observed still at the breakpoint, so the resume and the disabling of the breakpoint had not been processed, yet. It might be worth having an "ack" returned when the "quit" is processed in the debugee. ... On 2/1/19, 2:15 PM, serguei.spit...@oracle.com wrote: Hi Gary, The debugee.quit() is to complete the session. It makes this call: sendSignal(SGNL_QUIT); A call to the debugee.quit() is at the end of execTest() method: 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 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 +++ b/test/hotspot/jtreg/ProblemList.txt @@ -163,7 +163,6 @@ vmTestbase/nsk/jdi/EventRequest/setEnabled/setenabled003/TestDescription.java 8066993 generic-all vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses021/TestDescription.java 8065773 generic-all vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses023/TestDescription.java 8065773 generic-all -vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005/TestDescription.java 8068225 generic-all vmTestbase/metaspace/gc/firstGC_10m/TestDescription.java 8208250 generic-all vmTestbase/metaspace/gc/firstGC_50m/TestDescription.java 8208250 generic-all diff --git a/test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005.java b/test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005.java --- a/test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005.java +++ b/test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2002, 2018, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2002, 2019, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -134,6 +134,7 @@ } display(""); } + debugee.sendSignal(SGNL_QUIT); display(""); display("=");
Re: RFR: JDK-8068225: nsk/jdi/EventQueue/remove_l/remove_l005 intermittently times out
Testing an alternate fix that will wait for the debugee process to terminate after processing the "quit" command before doing the vm tear down. diff --git a/test/hotspot/jtreg/vmTestbase/nsk/share/jdi/Debugee.java b/test/hotspot/jtreg/vmTestbase/nsk/share/jdi/Debugee.java --- a/test/hotspot/jtreg/vmTestbase/nsk/share/jdi/Debugee.java +++ b/test/hotspot/jtreg/vmTestbase/nsk/share/jdi/Debugee.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2001, 2018, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2001, 2019, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -557,6 +557,7 @@ * exit status code. */ public int endDebugee() { +int status = waitFor(); if (vm != null) { 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 other tests with a similar failure mode. I'm attempting to get some additional diagnostic information from these tests with "-jdi.trace=all", but the diagnostic output may be interfering with the timing. My current investigation is around a possible race condition in the Debgugee.quit() processing. - the "quit" string is sent to the deuggee via the IOpipe - the vm.dispose() is handled from the JDWP communication If the context switching is not quick enough, the debugee may not have read and processed the "quit" command before tear down is handled. From earlier comments in the bug report the debuggee was observed still at the breakpoint, so the resume and the disabling of the breakpoint had not been processed, yet. It might be worth having an "ack" returned when the "quit" is processed in the debugee. ... On 2/1/19, 2:15 PM, serguei.spit...@oracle.com wrote: Hi Gary, The debugee.quit() is to complete the session. It makes this call: sendSignal(SGNL_QUIT); A call to the debugee.quit() is at the end of execTest() method: 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 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 +++ b/test/hotspot/jtreg/ProblemList.txt @@ -163,7 +163,6 @@ vmTestbase/nsk/jdi/EventRequest/setEnabled/setenabled003/TestDescription.java 8066993 generic-all vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses021/TestDescription.java 8065773 generic-all vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses023/TestDescription.java 8065773 generic-all -vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005/TestDescription.java 8068225 generic-all vmTestbase/metaspace/gc/firstGC_10m/TestDescription.java 8208250 generic-all vmTestbase/metaspace/gc/firstGC_50m/TestDescription.java 8208250 generic-all diff --git a/test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005.java b/test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005.java --- a/test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005.java +++ b/test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2002, 2018, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2002, 2019, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -134,6 +134,7 @@ } display(""); } +debugee.sendSignal(SGNL_QUIT); display(""); display("=");
Re: RFR: JDK-8068225: nsk/jdi/EventQueue/remove_l/remove_l005 intermittently times out
Just a quick update on the failure on shutdown ... I've come across a couple of other tests with a similar failure mode. I'm attempting to get some additional diagnostic information from these tests with "-jdi.trace=all", but the diagnostic output may be interfering with the timing. My current investigation is around a possible race condition in the Debgugee.quit() processing. - the "quit" string is sent to the deuggee via the IOpipe - the vm.dispose() is handled from the JDWP communication If the context switching is not quick enough, the debugee may not have read and processed the "quit" command before tear down is handled. From earlier comments in the bug report the debuggee was observed still at the breakpoint, so the resume and the disabling of the breakpoint had not been processed, yet. It might be worth having an "ack" returned when the "quit" is processed in the debugee. ... On 2/1/19, 2:15 PM, serguei.spit...@oracle.com wrote: Hi Gary, The debugee.quit() is to complete the session. It makes this call: sendSignal(SGNL_QUIT); A call to the debugee.quit() is at the end of execTest() method: 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 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 +++ b/test/hotspot/jtreg/ProblemList.txt @@ -163,7 +163,6 @@ vmTestbase/nsk/jdi/EventRequest/setEnabled/setenabled003/TestDescription.java 8066993 generic-all vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses021/TestDescription.java 8065773 generic-all vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses023/TestDescription.java 8065773 generic-all -vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005/TestDescription.java 8068225 generic-all vmTestbase/metaspace/gc/firstGC_10m/TestDescription.java 8208250 generic-all vmTestbase/metaspace/gc/firstGC_50m/TestDescription.java 8208250 generic-all diff --git a/test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005.java b/test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005.java --- a/test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005.java +++ b/test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2002, 2018, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2002, 2019, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -134,6 +134,7 @@ } display(""); } +debugee.sendSignal(SGNL_QUIT); display(""); display("=");
Re: RFR: JDK-8068225: nsk/jdi/EventQueue/remove_l/remove_l005 intermittently times out
Hi Gary, The debugee.quit() is to complete the session. It makes this call: sendSignal(SGNL_QUIT); A call to the debugee.quit() is at the end of execTest() method: 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 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 +++ b/test/hotspot/jtreg/ProblemList.txt @@ -163,7 +163,6 @@ vmTestbase/nsk/jdi/EventRequest/setEnabled/setenabled003/TestDescription.java 8066993 generic-all vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses021/TestDescription.java 8065773 generic-all vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses023/TestDescription.java 8065773 generic-all -vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005/TestDescription.java 8068225 generic-all vmTestbase/metaspace/gc/firstGC_10m/TestDescription.java 8208250 generic-all vmTestbase/metaspace/gc/firstGC_50m/TestDescription.java 8208250 generic-all diff --git a/test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005.java b/test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005.java --- a/test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005.java +++ b/test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2002, 2018, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2002, 2019, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -134,6 +134,7 @@ } display(""); } + debugee.sendSignal(SGNL_QUIT); display(""); display("=");
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 +++ b/test/hotspot/jtreg/ProblemList.txt @@ -163,7 +163,6 @@ vmTestbase/nsk/jdi/EventRequest/setEnabled/setenabled003/TestDescription.java 8066993 generic-all vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses021/TestDescription.java 8065773 generic-all vmTestbase/nsk/jdi/VirtualMachine/redefineClasses/redefineclasses023/TestDescription.java 8065773 generic-all -vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005/TestDescription.java 8068225 generic-all vmTestbase/metaspace/gc/firstGC_10m/TestDescription.java 8208250 generic-all vmTestbase/metaspace/gc/firstGC_50m/TestDescription.java 8208250 generic-all diff --git a/test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005.java b/test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005.java --- a/test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005.java +++ b/test/hotspot/jtreg/vmTestbase/nsk/jdi/EventQueue/remove_l/remove_l005.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2002, 2018, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2002, 2019, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -134,6 +134,7 @@ } display(""); } +debugee.sendSignal(SGNL_QUIT); display(""); display("=");