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

[Chris Plummer]

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