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. ------------- Commit messages: - Don't expect Windows be able to dump the SteadyStateThread context. Changes: https://git.openjdk.java.net/jdk/pull/7259/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7259&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280770 Stats: 20 lines in 1 file changed: 12 ins; 4 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/7259.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7259/head:pull/7259 PR: https://git.openjdk.java.net/jdk/pull/7259
