Actually at the moment this is not a test failure since the test does not detect the exception and passes anyway. It will start to fail once JDK-8234277 is pushed and does more error checking on the clhsdb output. What I'm seeing in the ClhsdbScanOops.java on linux-x64 is the following:

0x00000006c6eb4528 java/lang/String
0x00000006c6eb45b8 java/lang/String
0x00000006c6eb45f0 java/lang/String
0x00000006c6eb47c8 java/lang/String
Error: sun.jvm.hotspot.types.WrongTypeException: No suitable match for type of address 0x0000000800000028
sun.jvm.hotspot.types.WrongTypeException: No suitable match for type of address 0x0000000800000028
at jdk.hotspot.agent/sun.jvm.hotspot.runtime.InstanceConstructor.newWrongTypeException(InstanceConstructor.java:62)
at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VirtualBaseConstructor.instantiateWrapperFor(VirtualBaseConstructor.java:109)
at jdk.hotspot.agent/sun.jvm.hotspot.oops.Metadata.instantiateWrapperFor(Metadata.java:74)
at jdk.hotspot.agent/sun.jvm.hotspot.utilities.RobustOopDeterminator.oopLooksValid(RobustOopDeterminator.java:73)
at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor$33.doit(CommandProcessor.java:1187)
at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1983)
at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1953)
at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1833)
at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:99)
at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:40)
at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runCLHSDB(SALauncher.java:270)
at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:406)

But since the output the test is looking for is still there, the test passes. The changes for JDK-8234277 will do additional output error checking and detect this exception. As a result the test will fail on linux-x64 every time.

On windows-x64, this test always runs into JDK-8230731, so it never sees this particular error. However, even JDK-8230731 does not cause this test to fail since it still finds the output it is looking for, but the extra error checking done by JDK-8234277 will cause it to start to fail every time on windows-x64 also.

On macosx-x64 the failure is different as it sees a NullPointerException rather than the WrongTypeException seen on linux-x64. This also would normally not cause the test to fail, but does after JDK-8234277. It's unclear if this is related to the linux-x64 failure. A separate bug may need to be filed for it.

0x00000007aaba9268 java/lang/String
0x00000007aaba92a0 java/lang/String
0x00000007aaba9478 java/lang/String
Error: java.lang.NullPointerException
java.lang.NullPointerException
at jdk.hotspot.agent/sun.jvm.hotspot.memory.FileMapInfo$FileMapHeader.inCopiedVtableSpace(FileMapInfo.java:124)
at jdk.hotspot.agent/sun.jvm.hotspot.memory.FileMapInfo.inCopiedVtableSpace(FileMapInfo.java:104)
at jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicTypeDataBase.findDynamicTypeForAddress(BasicTypeDataBase.java:302)
at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VirtualBaseConstructor.instantiateWrapperFor(VirtualBaseConstructor.java:102)
at jdk.hotspot.agent/sun.jvm.hotspot.oops.Metadata.instantiateWrapperFor(Metadata.java:74)
at jdk.hotspot.agent/sun.jvm.hotspot.utilities.RobustOopDeterminator.oopLooksValid(RobustOopDeterminator.java:73)
at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor$33.doit(CommandProcessor.java:1187)
at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1983)
at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1953)
at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1833)
at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:99)
at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:40)
at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runCLHSDB(SALauncher.java:270)
at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:406)