On Thu, 11 Jul 2024 07:13:17 GMT, David Holmes <dhol...@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
