On Mon, 4 Oct 2021 14:07:18 GMT, Richard Reingruber wrote:
> This change fixes the deadlock described in the JBS-bug by:
>
> * Releasing `handlerLock` before waiting on `threadLock` in
> `blockOnDebuggerSuspend()`
>
> * Notifying on `threadLock` after resuming all threads in
> `threadControl_
On Tue, 5 Oct 2021 20:56:43 GMT, Chris Plummer wrote:
>> Regarding threadControl_resumeThread() it does appear that it would block,
>> as would threadControl_resumeAll(), which seems problematic in that
>> blockOnDebuggerSuspend() won't exit until the suspendCount == 0. So it's
>> unclear to m
On Tue, 5 Oct 2021 20:28:36 GMT, Chris Plummer wrote:
>>> I'm not so sure this is always safe. It might be fine in the context of
>>> resetting the connection, but not during normal debug agent operations. It
>>> allows for another event to be processed when the lock is suppose to keep
>>> event
On Tue, 5 Oct 2021 13:54:46 GMT, Richard Reingruber wrote:
>> src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c line 750:
>>
>>> 748: while (node && node->suspendCount > 0) {
>>> 749: /* Resume requires the event handlerLock so we have to
>>> release it */
>>> 750:
On Tue, 5 Oct 2021 05:31:37 GMT, Chris Plummer wrote:
> I'm not so sure this is always safe. It might be fine in the context of
> resetting the connection, but not during normal debug agent operations. It
> allows for another event to be processed when the lock is suppose to keep
> event processi
On Mon, 4 Oct 2021 14:07:18 GMT, Richard Reingruber wrote:
> This change fixes the deadlock described in the JBS-bug by:
>
> * Releasing `handlerLock` before waiting on `threadLock` in
> `blockOnDebuggerSuspend()`
>
> * Notifying on `threadLock` after resuming all threads in
> `threadControl_
