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

[gary.adams at oracle.com]

I'll make a pass over the code for cosmetic fixes after the test
is working correctly.

I think the purpose of the lockingObject is to ensure the debugger
has time to enable the breakpoint and perform the double resume
before debuggee thread2 is released to run to the expected breakpoint.

I'm assuming the timeout and break point location are correct, because
the test passes most of the time. I'll dump the values to make sure.

I'll also try to capture a thread dump at the time of the timeout,
to see if the debuggee is hung somewhere unexpected.

The test leaves the main thread suspended while thread2 is
is resumed. I'll see if resuming the main thread unblocks thread2.

...

On 2/21/19 10:18 PM, serguei.spitsyn at oracle.com wrote:
> Hi Gary,
>
> I do not see any cause of this timeout yet.
> However, the synchronization on the lockingObject looks completely 
> wasteful.
> Moreover, it adds unreasonable complexity and makes the test harder to 
> understand.
>
> So, I'd suggested to do a small cleanup that includes:
>   - removing the lockingObject field and sync around it
>   - fix wrong indents in the fragment:
>   161         synchronized (waitnotifyObj)                    {
>   162             log("entered into block:  synchronized (waitnotifyObj)");
>   163             waitnotifyObj.notify();                     }
>
> Thanks,
> Serguei
>
>
> On 2/21/19 10:57, gary.adams at oracle.com wrote:
>> The commented out "docontinue" was done to match the style
>> used in the other tests. I'll remove it for this test.
>>
>> In any event, the test still is failing 8 / 500 testruns on
>> macosx and windows debug builds.
>>
>> The change is not sufficient.
>>
>> Here's a recent failure. You can see in the log that the debugger did
>> wait until the new "docontinue" arrives outside the lockingObject
>> synchronized block.
>>
>> It appears with the main thread suspended and the thread2 double resumed,
>> it still does not continue executing up to the breakpoint in thread2.
>> After the eventQueue.remove(timeout), when the vm is resumed
>> you can see the debuggee messages expected leading up to the breakpoint.
>>
>> ...
>>
>> --> debugger:       suspending VM with vm.suspend();
>> *debugee.stderr> **> mainThread: mainThread is out of: synchronized 
>> (lockingObject) {*
>> --> debugger:          thread2.suspendCount() == 2
>> --> debugger:      :   thread2.isSuspended()
>> --> debugger:          mainThread.suspendCount() == 1
>> --> debugger:      :   mainThread.isSuspended()
>> --> debugger:       double resuming thread2 with thread2.resume();
>> --> debugger:          thread2.suspendCount() == 1
>> --> debugger:      :   thread2.isSuspended()
>> --> debugger:      enabling breakpRequest1
>> --> debugger:          thread2.suspendCount() == 0
>> --> debugger:      :  !thread2.isAtBreakpoint() before call to breakpoint()
>> --> debugger:        waiting for BreakpointEvent
>> *--> debugger: new: eventSet = eventQueue.remove();*
>> # ERROR: ##> debugger: ERROR:  timeout for waiting for a BreakpintEvent
>> The following stacktrace is for failure analysis.
>> nsk.share.TestFailure: ##> debugger: ERROR:  timeout for waiting for a BreakpintEvent
>> 	at nsk.share.Log.logExceptionForFailureAnalysis(Log.java:428)
>> 	at nsk.share.Log.complain(Log.java:399)
>> 	at nsk.jdi.ThreadReference.isSuspended.issuspended002.log3(issuspended002.java:104)
>> 	at nsk.jdi.ThreadReference.isSuspended.issuspended002.breakpoint(issuspended002.java:555)
>> 	at nsk.jdi.ThreadReference.isSuspended.issuspended002.runThis(issuspended002.java:389)
>> 	at nsk.jdi.ThreadReference.isSuspended.issuspended002.run(issuspended002.java:90)
>> 	at nsk.jdi.ThreadReference.isSuspended.issuspended002.main(issuspended002.java:85)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>> 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> 	at java.base/java.lang.reflect.Method.invoke(Method.java:567)
>> 	at PropertyResolvingWrapper.main(PropertyResolvingWrapper.java:104)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>> 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> 	at java.base/java.lang.reflect.Method.invoke(Method.java:567)
>> 	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>> 	at java.base/java.lang.Thread.run(Thread.java:835)
>> *--> debugger: resuming both second and main thread debugee.stderr> 
>> **> mainThread: waiting for an instruction from the debugger ... --> 
>> debugger: the end of testing debugee.stderr> **> thread2: entered 
>> into block: synchronized (lockingObject) debugee.stderr> **> thread2: 
>> exited from block: synchronized (lockingObject) debugee.stderr> **> 
>> thread2: call to the method 'runt1' debugee.stderr> **> thread2: 
>> method 'runt1' enter*
>> --> debugger:      : returned string is 'checkend'
>> debugee.stderr> **> mainThread: waiting for an instruction from the debugger ...
>>
>>
>> On 2/20/19 5:15 PM, Alex Menkov wrote:
>>> +1
>>>
>>> But could you please remove old "pipe.println("docontinue")" 
>>> statement instead of commenting it out (no new webrev is required)
>>>
>>> --alex
>>>
>>> On 02/20/2019 09:58, Chris Plummer wrote:
>>>> Looks good.
>>>>
>>>> Chris
>>>>
>>>> On 2/20/19 7:57 AM, Gary Adams wrote:
>>>>> The issuspended002 has been on the ProblemList since the tests 
>>>>> were moved to
>>>>> the open repos. The proposed changeset applies the same fix that 
>>>>> was used in issuspended001.
>>>>>
>>>>> The current test fails when the debuggee replies with the 
>>>>> "docontinue" response,
>>>>> while it is still holding a lock in a syncrhonized block. When the 
>>>>> debugger then
>>>>> suspends the vm the debuggee test thread fails to proceed to the 
>>>>> expected breakpoint.
>>>>> Testing in progress.
>>>>>
>>>>>   Issue: https://bugs.openjdk.java.net/browse/JDK-4903717
>>>>>   Webrev: http://cr.openjdk.java.net/~gadams/4903717/webrev.00/
>>>>
>>>>
>>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20190222/4fe1ed3e/attachment.html>