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

[Chris Plummer]

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