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

[Chris Plummer]

On Thu, 11 Jul 2024 07:13:17 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Which logging should be removed? Alex suggest the logging between breakpoints 2 and 3, but even that is not enough. There is logging after breakpoint 3, and that happens before the vm.resume() is done. I'm not saying this can't be done right, but I think pruning out logging like this in order to fix the problem not only removes some valuable logging from the test, but still leaves us open to this type of issue.
>> 
>> I think the safer thing to do is to make sure mainThread is no longer logging (or will attempt to log) when the vmsuspend is done. This could be done by pruning some of its logging, but that has the same negatives as removing some thread2 logging. My sleep suggestion is by far the simplest. The "purist" fix would probably be the checkpoint approach (don't do the vm.suspend until mainThread has reached a stable point). That ended up getting a bit uglier than I had hoped, but I can finish up the work so you can have a look at it if you'd like.
>
> Sorry I'm unclear on the different threads involved here. IIUC the vm.suspend comes from the debugger, and the mainthread and thread-2 are both threads in the debuggee, being suspended at different times?

Yes. thread2 is suspended via breakpoint (multiple times). mainThread is suspended by the one place in the test that does a vm.suspend(), which is near the end of the test. This is the problematic suspend because sometimes it is done while mainThread is in the middle of a println. A bit later thread2 is resumed and ends up blocking on a println due to mainThread holding the needed lock.

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

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