RFR: JDK-8215550: Debugger does not work after reattach

[gary.adams at oracle.com]

Issuing a "cont" in the second session does not work, because
the threads are not suspended.

It's interesting that the thread ids have all changed in
the reconnected session.

...

main[1] threads
Group system:
   (java.lang.ref.Reference$ReferenceHandler)0x374 Reference Handler running
   (java.lang.ref.Finalizer$FinalizerThread)0x375 Finalizer         
cond. waiting
   (java.lang.Thread)0x376                         Signal Dispatcher running
Group main:
   (java.lang.Thread)0x1 main              running (at breakpoint)
Group InnocuousThreadGroup:
   (jdk.internal.misc.InnocuousThread)0x377 Common-Cleaner    cond. waiting
main[1] exit
...
 > threads
Group system:
   (java.lang.ref.Reference$ReferenceHandler)0x3b2 Reference Handler running
   (java.lang.ref.Finalizer$FinalizerThread)0x3b3 Finalizer         
cond. waiting
   (java.lang.Thread)0x3b4                         Signal Dispatcher running
Group main:
   (java.lang.Thread)0x3b7 main              running
Group InnocuousThreadGroup:
   (jdk.internal.misc.InnocuousThread)0x3b8 Common-Cleaner    cond. waiting
 > cont
 > Nothing suspended.






On 1/29/19 2:27 PM, Chris Plummer wrote:
> What is the state of the threads after the detach? If they are all 
> automatically resumed by the agent, then I think the unblocking should 
> be done by the same code that resumes the threads. If they are still 
> suspended, then why would we want to unblock when the next connection 
> comes in? It should be up to the debugger to detect that all threads 
> are suspended and act accordingly.
>
> Also, what happens if after attaching again you issue a "cont" command?
>
> Chris
>
> On 1/29/19 9:55 AM, Gary Adams wrote:
>> As far as I can tell, the quit and exit commands are only handled 
>> locally
>> on the debugger side of the connection. There is no packet sent to the
>> libjdwp agentlib.
>>
>> On 1/29/19, 12:17 PM, Chris Plummer wrote:
>>> Hi Gary,
>>>
>>> When the "exit" or "quit" is done, aren't all threads resumed at 
>>> that point, and shouldn't that result in the command loop being 
>>> unblocked?
>>>
>>> thanks,
>>>
>>> Chris
>>>
>>> On 1/29/19 8:09 AM, Gary Adams wrote:
>>>> Significant protections are put in place to protect the commandLoop
>>>> from multiple events that that have a suspend-all policy. The
>>>> commandLoop uses a special block variable to ensure only
>>>> a VirtualMachine or ThreadReference call to resume() will unblock
>>>> the commandLoop. See
>>>>
>>>>   src/jdk.jdwp.agent/share/native/libjdwp/eventHelper.c
>>>>
>>>> In this particular bug report, the user was stopped at a breakpoint
>>>> when they sent the "exit" command. The same effect can be produced
>>>> with a "quit" command or any killing of the debugger process.
>>>>
>>>> When the second session is started the commandLoop is still blocked,
>>>> so a new breakpoint will never be dequeued from the commandQueue.
>>>>
>>>> The proposed workaround will ensure the commandLoop is unblocked
>>>> when a new session is started.
>>>>
>>>>   Issue: https://bugs.openjdk.java.net/browse/JDK-8215550
>>>>   Webrev: http://cr.openjdk.java.net/~gadams/8215550/webrev.00/
>>>>
>>>> All testing has been done by manually replicating the reported
>>>> command sequences. I'll see if an existing breakpoint test can be
>>>> enhanced to cover this scenario.
>>>
>>>
>>>
>>
>
>