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.
