On Thu, 29 May 2025 21:39:37 GMT, Alex Menkov <amen...@openjdk.org> wrote:
>> Thanks for explanation. Can you please add corresponding comment. The >> volatile counters are rare thing... > > I think the evaluation is not correct (lack of synchronization is an issue > too). > main thread also writes the value and I think this is the problem here. > Look at line 148 - it resets `counter1` instead of `counter2` and this > happens after the test sends `COMMAND_TEST1`. So if listener thread already > handled caught exception, we get the failure. Yes, I noticed that, and I think the resetting is a bug. Probably left over from when the test was originally written. I think both of those resets can be removed. It only makes sense to reset the counters if first you check them and produce an error if one of them was unexpectedly set. For example, after the the first part of the test counter1 should be 1 and counter2 should be zero. After making that check, both counters should be reset. After the 2nd part it should verify that counter1 is 0 and counter2 is 1. However, this test does not have the needed synchronization to make those types of checks. So instead it waits for the debuggee to exit and then checks that both counters are not 0. Also, it could (should) just check for 1 intead. There should never be more than one of each exception event generated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25236#discussion_r2114976126
