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

[Chris Plummer]

Ok. Looks like the test is just making sure there are no errors (or the 
errors are expected) when creating the StepRequest, but doesn't not 
actually deal with any SingleStep events.

Fix looks good.

thanks,

Chris

On 6/5/19 8:03 PM, Daniil Titov wrote:
> Hi Chris,
>
>> and would not delete the single step request until the event has been received and the  thread is suspended.
> In this test there is no guarantee that this single step event is ever posted.  In the most of the cases by the time the step request
> is created the debuggee is already waiting on line 42 for blocking IO somewhere inside pipe.readlln(). And since the test sends the command to the pipe
> only after it deletes the step request the debuggee continues without posting the step event.
>
>
>    34	public class crstepreq001t {
>      35	    public static void main(String args[]) {
>      36	        ArgumentHandler argHandler = new ArgumentHandler(args);
>      37	        IOPipe pipe = argHandler.createDebugeeIOPipe();
>      38	        Thread  thr = Thread.currentThread();
>      39	
>      40	        thr.setName(crstepreq001.DEBUGGEE_THRD);
>      41	        pipe.println(crstepreq001.COMMAND_READY);
>      42	        String cmd = pipe.readln();
>      43	        if (!cmd.equals(crstepreq001.COMMAND_QUIT)) {
>      44	            System.err.println("TEST BUG: unknown debugger command: "
>      45	                + cmd);
>      46	            System.exit(crstepreq001.JCK_STATUS_BASE +
>      47	                crstepreq001.FAILED);
>      48	        }
>      49	        System.exit(crstepreq001.JCK_STATUS_BASE +
>      50	            crstepreq001.PASSED);
>      51	    }
>     
>
>
> Best regards,
> --Daniil
>
> On 6/5/19, 7:44 PM, "Chris Plummer" <chris.plummer at oracle.com> wrote:
>
>      Hi Daniil,
>      
>      I understand the general issues that the debugger might delete a request
>      after the event has already been generated but before the debugger has
>      received it. Alan and I recently had a discussion about this and
>      concluded that the debugger must be ready for this, otherwise the debug
>      agent will have suspended threads and the debugger might never do
>      anything to resume them (in fact I suspect I'm seeing this in a certain
>      debugger). However, for the case of this test I would think it would be
>      taking fine grain controlled over the requests and events, and would not
>      delete the single step request until the event has been received and the
>      thread is suspended. It can then delete the request and resume the
>      thread (or all threads if using SUSPEND_ALL). Is there a reason the test
>      is not already doing this?
>      
>      thanks,
>      
>      Chris
>      
>      On 6/5/19 7:36 PM, Daniil Titov wrote:
>      > Please review a change that fixes the intermittent failure of the test.
>      >
>      > The problem here that there is a chance that a single step event had been posted after the step request was created and before it was deleted.
>      >
>      > The fix solves this by ensuring that vm.resume() is called at the end of the test.
>      >
>      > Webrev: http://cr.openjdk.java.net/~dtitov/8206074/webrev.01
>      > Bug: https://bugs.openjdk.java.net/browse/JDK-8206074
>      >
>      > Thanks!
>      > --Daniil
>      >
>      >
>      >
>      
>      
>
>