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

2019-02-11 Thread Gary Adams
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

2019-02-10 Thread Chris Plummer

  
  
+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.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

2019-02-08 Thread Jean Christophe Beyler
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

2019-02-08 Thread serguei.spit...@oracle.com

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

2019-02-08 Thread Gary Adams
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

2019-02-06 Thread Chris Plummer
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

2019-02-06 Thread Gary Adams

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

2019-02-06 Thread Chris Plummer

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

2019-02-06 Thread Gary Adams

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

2019-02-06 Thread Chris Plummer
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

2019-02-06 Thread Gary Adams
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

2019-02-06 Thread Gary Adams

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

2019-02-01 Thread serguei.spit...@oracle.com

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

2019-02-01 Thread Gary Adams

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("=");