Following the trail from debugLoop_run, at the bottom of the loop
there is a path through debugInit_reset that involves eventHandler_reset
and eventually eventHelper_reset. This seems like a better place to
clear the flag back to original state.
Revised webrev: http://cr.openjdk.java.net/~gadams/8215550/webrev.01/
On 1/29/19, 6:11 PM, Chris Plummer wrote:
Ok, so you can't do a "cont" because threads are not suspended. That
means someone resumed them. When/where was this done?
Regarding threadIDs changing, my guess is that debugLoop_run() is
re-entered when the new connection is established. This will result in
commonRef_reset() being called, which invalidates all reference IDs,
including threadIDs. So the first time the agent needs to send a
threadID to the debugger, it needs to create a new one.
Chris
On 1/29/19 1:52 PM, gary.ad...@oracle.com wrote:
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.
