On Fri, 22 Oct 2021 17:48:36 GMT, Chris Plummer wrote:
>> Richard Reingruber has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Improve comment as suggested by Chris.
>
> Marked as reviewed by cjplummer (Reviewer).
Thanks for the reviews @
> This change fixes deadlocks described in the JBS-bug by:
>
> * Releasing `handlerLock` before waiting on `threadLock` in
> `blockOnDebuggerSuspend()`
>
> * Notifying on `threadLock` in `threadControl_reset()`
>
> Also the actions in handleAppResumeBreakpoint() are moved/deferred until
> doPen
On Mon, 8 Nov 2021 19:10:23 GMT, Ralf Schmelter wrote:
>> Richard Reingruber has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Improve comment as suggested by Chris.
>
> src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c line 812:
>
On Wed, 10 Nov 2021 09:55:30 GMT, Richard Reingruber wrote:
>> This change fixes deadlocks described in the JBS-bug by:
>>
>> * Releasing `handlerLock` before waiting on `threadLock` in
>> `blockOnDebuggerSuspend()`
>>
>> * Notifying on `threadLock` in `threadControl_reset()`
>>
>> Also the a
On Fri, 22 Oct 2021 06:21:37 GMT, Richard Reingruber wrote:
>> This change fixes deadlocks described in the JBS-bug by:
>>
>> * Releasing `handlerLock` before waiting on `threadLock` in
>> `blockOnDebuggerSuspend()`
>>
>> * Notifying on `threadLock` in `threadControl_reset()`
>>
>> Also the a
On Wed, 10 Nov 2021 01:24:58 GMT, Serguei Spitsyn wrote:
>> Richard Reingruber has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Improve comment as suggested by Chris.
>
> src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c line 2189:
> This change fixes deadlocks described in the JBS-bug by:
>
> * Releasing `handlerLock` before waiting on `threadLock` in
> `blockOnDebuggerSuspend()`
>
> * Notifying on `threadLock` in `threadControl_reset()`
>
> Also the actions in handleAppResumeBreakpoint() are moved/deferred until
> doPen
On Wed, 10 Nov 2021 01:27:40 GMT, Serguei Spitsyn wrote:
>> Richard Reingruber has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Improve comment as suggested by Chris.
>
> src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c line 2194:
On Fri, 22 Oct 2021 06:21:37 GMT, Richard Reingruber wrote:
>> This change fixes deadlocks described in the JBS-bug by:
>>
>> * Releasing `handlerLock` before waiting on `threadLock` in
>> `blockOnDebuggerSuspend()`
>>
>> * Notifying on `threadLock` in `threadControl_reset()`
>>
>> Also the a
On Fri, 22 Oct 2021 06:21:37 GMT, Richard Reingruber wrote:
>> This change fixes deadlocks described in the JBS-bug by:
>>
>> * Releasing `handlerLock` before waiting on `threadLock` in
>> `blockOnDebuggerSuspend()`
>>
>> * Notifying on `threadLock` in `threadControl_reset()`
>>
>> Also the a
On Fri, 22 Oct 2021 06:21:37 GMT, Richard Reingruber wrote:
>> This change fixes deadlocks described in the JBS-bug by:
>>
>> * Releasing `handlerLock` before waiting on `threadLock` in
>> `blockOnDebuggerSuspend()`
>>
>> * Notifying on `threadLock` in `threadControl_reset()`
>>
>> Also the a
On Fri, 22 Oct 2021 04:02:04 GMT, Chris Plummer wrote:
>> Richard Reingruber has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Hoist locking from trackAppResume() up to it its caller doPendingTasks()
>
> src/jdk.jdwp.agent/share/native/lib
> This change fixes deadlocks described in the JBS-bug by:
>
> * Releasing `handlerLock` before waiting on `threadLock` in
> `blockOnDebuggerSuspend()`
>
> * Notifying on `threadLock` in `threadControl_reset()`
>
> Also the actions in handleAppResumeBreakpoint() are moved/deferred until
> doPen
On Fri, 22 Oct 2021 04:04:13 GMT, Chris Plummer wrote:
>> I have hoisted the locking from `trackAppResume()` up to `doPendingTasks()`
>> where it is more visible. The change in that form is sufficient to fix the
>> deadlock issues. Would it be ok for you to do further enhancements in a
>> follow-
On Thu, 21 Oct 2021 19:38:41 GMT, Richard Reingruber wrote:
>> If you are worried about another thread changing those fields after they
>> have already been checked, then you can use the threadLock around them also.
>> So you can grab threadLock before the `if (node->handlingAppResume)` and
>>
On Thu, 21 Oct 2021 19:37:41 GMT, Richard Reingruber wrote:
>> This change fixes deadlocks described in the JBS-bug by:
>>
>> * Releasing `handlerLock` before waiting on `threadLock` in
>> `blockOnDebuggerSuspend()`
>>
>> * Notifying on `threadLock` in `threadControl_reset()`
>>
>> Also the a
On Thu, 21 Oct 2021 15:05:19 GMT, Chris Plummer wrote:
>>> move the locking and unlocking into doPendingTasks(). At the start of the
>>> node->handlingAppResume block, grab handlerLock and threadLock, and explain
>>> that handlerLock is being grabbed because trackAppResume() will (indirectly)
>>>
> This change fixes deadlocks described in the JBS-bug by:
>
> * Releasing `handlerLock` before waiting on `threadLock` in
> `blockOnDebuggerSuspend()`
>
> * Notifying on `threadLock` in `threadControl_reset()`
>
> Also the actions in handleAppResumeBreakpoint() are moved/deferred until
> doPen
On Thu, 21 Oct 2021 08:01:30 GMT, Richard Reingruber wrote:
>> BTW, normally I would not suggest less locking simply because I *thought* it
>> might not be needed. However, you already temporarily release and then
>> regrab the lock. This means there is a period of time where the locking is
>>
On Thu, 21 Oct 2021 03:34:30 GMT, Chris Plummer wrote:
>> You already release threadLock temporarily in `trackAppResume()` and you
>> used to release it temporarily in doPendingTasks(). I'm suggesting to
>> instead release it in `threadControl_onEventHandlerExit()` before calling
>> `doPending
On Thu, 21 Oct 2021 03:24:40 GMT, Chris Plummer wrote:
>> But fields of ThreadNode "node" (aka "resumer") are read and also modified
>> in `doPendingTasks()` and also in `threadControl_onEventHandlerExit()`. IMHO
>> this needs to be synchronized with threadLock. At least it is not obvious
>> t
On Wed, 20 Oct 2021 06:50:51 GMT, Richard Reingruber wrote:
>> src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c line 770:
>>
>>> 768: * handlerLock which has to be acquired before threadLock.
>>> 769: */
>>> 770: debugMonitorExit(threadLock);
>>
>> I think we can avoid the
> This change fixes deadlocks described in the JBS-bug by:
>
> * Releasing `handlerLock` before waiting on `threadLock` in
> `blockOnDebuggerSuspend()`
>
> * Notifying on `threadLock` in `threadControl_reset()`
>
> Also the actions in handleAppResumeBreakpoint() are moved/deferred until
> doPen
On Tue, 19 Oct 2021 20:21:59 GMT, Chris Plummer wrote:
>> Richard Reingruber has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Call blockOnDebuggerSuspend() after setup of the resumer tracking.
>
> src/jdk.jdwp.agent/share/native/libjdwp/t
On Tue, 19 Oct 2021 20:17:59 GMT, Chris Plummer wrote:
>> Richard Reingruber has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Call blockOnDebuggerSuspend() after setup of the resumer tracking.
>
> src/jdk.jdwp.agent/share/native/libjdwp/t
On Mon, 18 Oct 2021 20:02:21 GMT, Richard Reingruber wrote:
>> This change fixes deadlocks described in the JBS-bug by:
>>
>> * Releasing `handlerLock` before waiting on `threadLock` in
>> `blockOnDebuggerSuspend()`
>>
>> * Notifying on `threadLock` in `threadControl_reset()`
>>
>> Also the a
On Fri, 15 Oct 2021 11:52:09 GMT, Richard Reingruber wrote:
>
>
> Hm, I think this can be simplified by swaping blockOnDebuggerSuspend() and
> trackAppResume(). Can't try it today but will on Monday.
I've done that with commit
https://github.com/openjdk/jdk/pull/5849/commits/0b0fef0e6670c20a
> This change fixes deadlocks described in the JBS-bug by:
>
> * Releasing `handlerLock` before waiting on `threadLock` in
> `blockOnDebuggerSuspend()`
>
> * Notifying on `threadLock` in `threadControl_reset()`
>
> Also the actions in handleAppResumeBreakpoint() are moved/deferred until
> doPen
On Fri, 15 Oct 2021 09:17:12 GMT, Richard Reingruber wrote:
>> Ok. So you just need to reacquire the threadLock before the `findThread()`
>> call and before exiting the while loop, and hold it until after the
>> `trackAppResume()` call. I guess it ok then. But this exiting of the
>> handlerLoc
On Thu, 14 Oct 2021 18:33:51 GMT, Chris Plummer wrote:
>>> Ok, so you need to hold threadLock from the time `blockOnDebuggerSuspend()`
>>> is done waiting on it until after `trackAppResume()` is done, and since
>>> `trackAppResume()` needs to grab the handlerLock, and you need to grab the
>>>
> This change fixes deadlocks described in the JBS-bug by:
>
> * Releasing `handlerLock` before waiting on `threadLock` in
> `blockOnDebuggerSuspend()`
>
> * Notifying on `threadLock` in `threadControl_reset()`
>
> Also the actions in handleAppResumeBreakpoint() are moved/deferred until
> doPen
On Thu, 14 Oct 2021 07:44:36 GMT, Richard Reingruber wrote:
>> Ok, so you need to hold threadLock from the time `blockOnDebuggerSuspend()`
>> is done waiting on it until after `trackAppResume()` is done, and since
>> `trackAppResume()` needs to grab the handlerLock, and you need to grab the
>>
On Wed, 13 Oct 2021 20:59:44 GMT, Chris Plummer wrote:
> Ok, so you need to hold threadLock from the time `blockOnDebuggerSuspend()`
> is done waiting on it until after `trackAppResume()` is done, and since
> `trackAppResume()` needs to grab the handlerLock, and you need to grab the
> handerLo
On Wed, 13 Oct 2021 13:24:06 GMT, Richard Reingruber wrote:
>> src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c line 2220:
>>
>>> 2218: * suspends a thread it will remain suspended.
>>> 2219: */
>>> 2220: trackAppResume(resumer);
>>
>> `trackAppResum
> This change fixes deadlocks described in the JBS-bug by:
>
> * Releasing `handlerLock` before waiting on `threadLock` in
> `blockOnDebuggerSuspend()`
>
> * Notifying on `threadLock` in `threadControl_reset()`
>
> Also the actions in handleAppResumeBreakpoint() are moved/deferred until
> doPen
On Tue, 12 Oct 2021 22:55:05 GMT, Chris Plummer wrote:
>> Richard Reingruber has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Improve @summary section of test.
>
> src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c line 2200:
>
>> 2
On Wed, 13 Oct 2021 07:06:17 GMT, Chris Plummer wrote:
>> Richard Reingruber has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Improve @summary section of test.
>
> src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c line 750:
>
>> 74
On Tue, 12 Oct 2021 21:45:03 GMT, Chris Plummer wrote:
>> Richard Reingruber has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Improve @summary section of test.
>
> test/jdk/com/sun/jdi/ResumeAfterThreadResumeCallTest.java line 100:
>
>>
On Tue, 12 Oct 2021 21:39:35 GMT, Chris Plummer wrote:
>> Richard Reingruber has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Improve @summary section of test.
>
> test/jdk/com/sun/jdi/ResumeAfterThreadResumeCallTest.java line 159:
>
>>
On Tue, 12 Oct 2021 21:35:59 GMT, Chris Plummer wrote:
>> Richard Reingruber has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Improve @summary section of test.
>
> test/jdk/com/sun/jdi/ResumeAfterThreadResumeCallTest.java line 165:
>
>>
On Tue, 12 Oct 2021 21:06:00 GMT, Chris Plummer wrote:
>> Richard Reingruber has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Improve @summary section of test.
>
> test/jdk/com/sun/jdi/ResumeAfterThreadResumeCallTest.java line 81:
>
>> 7
On Tue, 12 Oct 2021 08:03:22 GMT, Richard Reingruber wrote:
>> This change fixes deadlocks described in the JBS-bug by:
>>
>> * Releasing `handlerLock` before waiting on `threadLock` in
>> `blockOnDebuggerSuspend()`
>>
>> * Notifying on `threadLock` in `threadControl_reset()`
>>
>> Also the a
On Tue, 12 Oct 2021 08:03:22 GMT, Richard Reingruber wrote:
>> This change fixes deadlocks described in the JBS-bug by:
>>
>> * Releasing `handlerLock` before waiting on `threadLock` in
>> `blockOnDebuggerSuspend()`
>>
>> * Notifying on `threadLock` in `threadControl_reset()`
>>
>> Also the a
On Tue, 12 Oct 2021 05:59:28 GMT, Chris Plummer wrote:
>> Richard Reingruber has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Improve @summary section of test.
>
> test/jdk/com/sun/jdi/ResumeAfterThreadResumeCallTest.java line 31:
>
>> 2
> This change fixes deadlocks described in the JBS-bug by:
>
> * Releasing `handlerLock` before waiting on `threadLock` in
> `blockOnDebuggerSuspend()`
>
> * Notifying on `threadLock` in `threadControl_reset()`
>
> Also the actions in handleAppResumeBreakpoint() are moved/deferred until
> doPen
> This change fixes deadlocks described in the JBS-bug by:
>
> * Releasing `handlerLock` before waiting on `threadLock` in
> `blockOnDebuggerSuspend()`
>
> * Notifying on `threadLock` in `threadControl_reset()`
>
> Also the actions in handleAppResumeBreakpoint() are moved/deferred until
> doPen
> This change fixes deadlocks described in the JBS-bug by:
>
> * Releasing `handlerLock` before waiting on `threadLock` in
> `blockOnDebuggerSuspend()`
>
> * Notifying on `threadLock` in `threadControl_reset()`
>
> Also the actions in handleAppResumeBreakpoint() are moved/deferred until
> doPen
On Thu, 7 Oct 2021 13:50:49 GMT, Richard Reingruber wrote:
> This change fixes deadlocks described in the JBS-bug by:
>
> * Releasing `handlerLock` before waiting on `threadLock` in
> `blockOnDebuggerSuspend()`
>
> * Notifying on `threadLock` in `threadControl_reset()`
>
> Also the actions in
This change fixes deadlocks described in the JBS-bug by:
* Releasing `handlerLock` before waiting on `threadLock` in
`blockOnDebuggerSuspend()`
* Notifying on `threadLock` in `threadControl_reset()`
Also the actions in handleAppResumeBreakpoint() are moved/deferred until
doPendingTasks() runs.
49 matches
Mail list logo
