On Fri, 28 Jan 2022 07:34:21 GMT, Chris Plummer <cjplum...@openjdk.org> wrote:
> The test does a "threadcontext -v -a", and from the following output > determines the threadID of the SteadyStateThread: > > `Thread "SteadyStateThread" id=23 Address=0x000001dc51749420` > > It then tries threadcontext on this id, but it fails: > > > + threadcontext -v 23 > Couldn't find thread 23 > > > This only happens on Windows. It turns out that each time you attach on > Window, the threadID for a thread can change. Some added diagnostic output > showed that for the SteadyStateThread, it changed from 23 to 20, and there is > no thread with an ID of 23. > > The only way to make this this part of the test work Windows as expected is > to parse the output of "threadcontext -v -a" without first doing a detach, > and then doing the "threadcontext -v 23" without having to attach again. > Unfortunately the test infrastructure for Clhsdb tests (and specifically > ClhsdbLauncher) don't make this easy to do this. You can't easily see the > output without first detaching, and then attach again on the next command. > For this reason I've chosen to not verify the output of the "threadcontext -v > <id>" part of the test when running on Windows. ClhsdbLauncher will still do > the normal checks to make sure no exceptions or errors are present in the > output. I filed [JDK-8280971](https://bugs.openjdk.java.net/browse/JDK-8280971) to address the issue of the changing thread IDs on Windows. I'd like to move forward with the workaround in this test. Otherwise it will be problem listed since it is causing too much noise. ------------- PR: https://git.openjdk.java.net/jdk/pull/7259
