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.
