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

[Gary Adams]

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