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

Chris Plummer chris.plummer at oracle.com
Wed Feb 6 19:19:10 UTC 2019 

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

More information about the serviceability-dev mailing list