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.
