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. That seems bizarre. If this is a dump from our Java launcher then there should be no other threads created before the one that loads the JVM. That said I'm a little surprised we are doing "kernel debugging" here and so the "engine id" comes into play. But that said shouldn't we be using the stable "system id" for the threads not this "engine id" ? ------------- PR: https://git.openjdk.java.net/jdk/pull/7259
