RFR: 8072701: resume001 failed due to ERROR: timeout for waiting for a BreakpintEvent [v3]

Daniel D. Daugherty dcubed at openjdk.org
Fri Jul 12 22:38:58 UTC 2024


On Fri, 12 Jul 2024 17:02:56 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> The original code had 2 vm.resume() - one on them to match vm.suspend() and 2nd one to allow debugee to continue on error.
>> Now we have 3 vm.resume() - one is to match vm.suspend() (line 377) and 2 conditional (on error).
>> Theoretically we can get an error when both vm and thread2 are suspended, so 2 vm.resume() looks reasonable.
>> Anyway resume() is a nop if the thread is not suspended
>
> After reaching the 2nd breakpoint, which suspends thread2, we do a vm.suspend(), which bumps the thread2 suspendCount to 2. However, we do a eventSet.resume() after this, lowering the suspendCount to 1, and there is no error bailout point while the suspendCount is 2. Thus only 1 vm.resume() is needed in the error handling.

I think all this discussion about the number of `vm.resume()` calls that are needed
or not needed and the fact that one of those `vm.resume()` calls could be replaced
by a thread2.resume() call _perfectly_ illustrates just how complicated this test is.

Thanks for going thru the effort to get rid of the `sleep()` call. I appreciate it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20088#discussion_r1676519121


More information about the serviceability-dev mailing list