JDK-8347779 : sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java fails with Unable to deduce type of thread from address
  • Type: Bug
  • Component: hotspot
  • Sub-Component: svc-agent
  • Affected Version: 25
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux
  • CPU: aarch64
  • Submitted: 2025-01-15
  • Updated: 2025-02-10
  • Resolved: 2025-01-30
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 25
25 b09Fixed
Related Reports
Relates :  
JDK-8248252 - 4 sun/tools/jhsdb tests failed with "RuntimeException: Unable to deduce type of thread"
Relates :  
JDK-8348239 - SA does not know about DeoptimizeObjectsALotThread
Description
Today we were running into this error :
sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java on Linux aarch64, jdk25

stderr: [java.lang.RuntimeException: Unable to deduce type of thread from address 0x0000ffff34144e30 (expected type JavaThread, CompilerThread, MonitorDeflationThread, AttachListenerThread, StringDedupThread, NotificationThread, ServiceThread or JvmtiAgentThread)
at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:196)
at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.getJavaThreadAt(Threads.java:178)
at jdk.hotspot.agent/sun.jvm.hotspot.utilities.HeapHprofBinWriter.dumpStackTraces(HeapHprofBinWriter.java:828)
at jdk.hotspot.agent/sun.jvm.hotspot.utilities.HeapHprofBinWriter.write(HeapHprofBinWriter.java:460)
at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.writeHeapHprofBin(JMap.java:216)
at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.run(JMap.java:103)
at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278)
at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241)
at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134)
at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.main(JMap.java:202)
at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJMAP(SALauncher.java:344)
at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507)
Caused by: sun.jvm.hotspot.types.WrongTypeException: No suitable match for type of address 0x0000ffff34144e30
at jdk.hotspot.agent/sun.jvm.hotspot.runtime.InstanceConstructor.newWrongTypeException(InstanceConstructor.java:62)
at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VirtualConstructor.instantiateWrapperFor(VirtualConstructor.java:80)
at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:192)
... 11 more
Comments
Changeset: 04c24f18 Branch: master Author: Matthias Baesken <mbaesken@openjdk.org> Date: 2025-01-30 08:23:04 +0000 URL: https://git.openjdk.org/jdk/commit/04c24f18d554a57c537f3a77c5f6d0d03e7fc3d1
30-01-2025
I've created JDK-8348239 for the DeoptimizeObjectsALotThread issue. I'll begin work on it.
22-01-2025
I found the following: class DeoptimizeObjectsALotThread : public JavaThread { This was added a while back (2020) and SA does not know about it. Possibly you are stumbling across this. Did you run with -XX:+DeoptimizeObjectsALot? If not, I think what is likely is that threads just can't be safely walked at this point in time in the hotspot's execution. The test is "HeapDumpTestWithActiveProcess", so that means it is doing nothing to try to make sure that hotspot isn't doing anything at the time the heapdump is generated. We fully expect SA failures at times when used on an active VM. The test does try to deal with this: String output = HprofReader.getStack(file, 0); // We only require JShellToolProvider to be in the output if we did the // short sleep. If we did not, the java process may not have executed far // enough along to even start the main thread. if (doSleep && !output.contains("JShellToolProvider")) { // This check will very rarely fail due to not be able to get the stack trace // of the main thread do to it actively executing. See JDK-8269556. We retry once // if that happens. This failure is so rare that this should be enough to make it // extremely unlikely that we ever see this test fail again for this reason. if (!allowRetry) { throw new RuntimeException("'JShellToolProvider' missing from stdout/stderr"); } else { System.out.println("'JShellToolProvider' missing. Allow one retry."); return true; // Allow one retry } } However, this is when reading the hprof file. Your failure is with writing it by using "jhsdb jmap", and I don't see the test guarding against "jhsdb jmap" failures. Are there any other failure messages in the output (specifically for a non-zero exit code).
21-01-2025
Ok. What I was looking for in the output is the following: java.lang.RuntimeException: Test ERROR java.lang.RuntimeException: Expected to get exit value of [0], exit value is: [1] So that is expected given that "jhsdb jmap" failed with an exception. Since you are not running with -XX:+DeoptimizeObjectsALot, there should be no DeoptimizeObjectsALotThread, so that is not likely your problem. I think it is simply a case of jmap being run when the JVM is in an inconsistent state. The test should really try again when this happens, just like it does if reading the hprof file.
21-01-2025
[~mbaesken] I plan on filing a separate issue for the missing DeoptimizeObjectsALotThread support in SA.
21-01-2025
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/23213 Date: 2025-01-21 13:24:41 +0000
21-01-2025
Hi [~cjplummer] I created a PR for the test change . Do you want me to include HS changes in the same PR ? https://github.com/openjdk/jdk/blob/9c430c92257739730155df05f340fe144fd24098/src/hotspot/share/runtime/vmStructs.cpp#L1250 https://github.com/openjdk/jdk/blob/9c430c92257739730155df05f340fe144fd24098/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Threads.java#L196 (or do you plan to do another PR handling DeoptimizeObjectsALotThread ?)
21-01-2025
This seems to readily reproduce the "Unable to deduce type of thread" failure , so clearly we aren't testing it: make test TEST=serviceability/sa TEST_JOBS=14 TEST_VM_OPTS=-XX:+DeoptimizeObjectsALot
17-01-2025
> So we should, in case of failure, do here in the launch method https://github.com/openjdk/jdk/blob/398a580518b4e7961bdddf733e0a89ff25bc437a/test/jdk/sun/tools/jhsdb/JShellHeapDumpTest.java#L82 a second try to use jhsdb, correct ? Yes. The retry mechanism can be modeled after printStackTraces(). > https://github.com/openjdk/jdk/blob/9c430c92257739730155df05f340fe144fd24098/src/hotspot/share/runtime/vmStructs.cpp#L1250 Other question, should we add DeoptimizeObjectsALotThread to the list of known JavaThreads (would maybe be another JBS issue) ? Yes. I was going to try doing some SA test runs with -XX:+DeoptimizeObjectsALot enabled to see if there are any failures as a result.
17-01-2025
So we should, in case of failure, do here in the launch method https://github.com/openjdk/jdk/blob/398a580518b4e7961bdddf733e0a89ff25bc437a/test/jdk/sun/tools/jhsdb/JShellHeapDumpTest.java#L82 a second try to use jhsdb, correct ? > https://github.com/openjdk/jdk/blob/9c430c92257739730155df05f340fe144fd24098/src/hotspot/share/runtime/vmStructs.cpp#L1250 Other question, should we add DeoptimizeObjectsALotThread to the list of known JavaThreads (would maybe be another JBS issue) ?
17-01-2025
> Did you run with -XX:+DeoptimizeALot? No, cannot see this flag in the output. > Are there any other failure messages in the output (specifically for a non-zero exit code This it what I see in the output : [JShell] | Welcome to JShell -- Version 25-internal [JShell] | For an introduction type: /help intro Jshell Started in 8216ms Starting jmap against 4174636 [2025-01-14T03:51:56.109778330Z] Gathering output for process 4174728 [2025-01-14T03:51:56.178511392Z] Waiting for completion for process 4174728 [2025-01-14T03:52:04.128978686Z] Waiting for completion finished for process 4174728 Output and diagnostic info for process 4174728 was saved into 'pid-4174728-output.log' jhsdb jmap stdout: Attaching to process ID 4174636, please wait... Debugger attached successfully. Server compiler detected. JVM version is 25-internal-adhoc.jenkinsi.jdk jhsdb jmap stderr: java.lang.RuntimeException: Unable to deduce type of thread from address 0x0000ffff34144e30 (expected type JavaThread, CompilerThread, MonitorDeflationThread, AttachListenerThread, StringDedupThread, NotificationThread, ServiceThread or JvmtiAgentThread) at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:196) at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.getJavaThreadAt(Threads.java:178) at jdk.hotspot.agent/sun.jvm.hotspot.utilities.HeapHprofBinWriter.dumpStackTraces(HeapHprofBinWriter.java:828) at jdk.hotspot.agent/sun.jvm.hotspot.utilities.HeapHprofBinWriter.write(HeapHprofBinWriter.java:460) at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.writeHeapHprofBin(JMap.java:216) at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.run(JMap.java:103) at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278) at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241) at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134) at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.main(JMap.java:202) at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJMAP(SALauncher.java:344) at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507) Caused by: sun.jvm.hotspot.types.WrongTypeException: No suitable match for type of address 0x0000ffff34144e30 at jdk.hotspot.agent/sun.jvm.hotspot.runtime.InstanceConstructor.newWrongTypeException(InstanceConstructor.java:62) at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VirtualConstructor.instantiateWrapperFor(VirtualConstructor.java:80) at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:192) ... 11 more ###### End of all output which took 8125ms Destroying jshell Jshell destroyed ----------System.err:(44/3159)---------- stdout: [Attaching to process ID 4174636, please wait... Debugger attached successfully. Server compiler detected. JVM version is 25-internal-adhoc.jenkinsi.jdk ]; stderr: [java.lang.RuntimeException: Unable to deduce type of thread from address 0x0000ffff34144e30 (expected type JavaThread, CompilerThread, MonitorDeflationThread, AttachListenerThread, StringDedupThread, NotificationThread, ServiceThread or JvmtiAgentThread) at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:196) at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.getJavaThreadAt(Threads.java:178) at jdk.hotspot.agent/sun.jvm.hotspot.utilities.HeapHprofBinWriter.dumpStackTraces(HeapHprofBinWriter.java:828) at jdk.hotspot.agent/sun.jvm.hotspot.utilities.HeapHprofBinWriter.write(HeapHprofBinWriter.java:460) at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.writeHeapHprofBin(JMap.java:216) at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.run(JMap.java:103) at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278) at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241) at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134) at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.main(JMap.java:202) at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJMAP(SALauncher.java:344) at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507) Caused by: sun.jvm.hotspot.types.WrongTypeException: No suitable match for type of address 0x0000ffff34144e30 at jdk.hotspot.agent/sun.jvm.hotspot.runtime.InstanceConstructor.newWrongTypeException(InstanceConstructor.java:62) at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VirtualConstructor.instantiateWrapperFor(VirtualConstructor.java:80) at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:192) ... 11 more ] exitValue = 1 java.lang.RuntimeException: Test ERROR java.lang.RuntimeException: Expected to get exit value of [0], exit value is: [1] at JShellHeapDumpTest.launch(JShellHeapDumpTest.java:84) at JShellHeapDumpTest.launch(JShellHeapDumpTest.java:99) at JShellHeapDumpTest.testHeapDump(JShellHeapDumpTest.java:135) at JShellHeapDumpTest.main(JShellHeapDumpTest.java:196) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) at java.base/java.lang.reflect.Method.invoke(Method.java:565) at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138) at java.base/java.lang.Thread.run(Thread.java:1447) Caused by: java.lang.RuntimeException: Expected to get exit value of [0], exit value is: [1] at jdk.test.lib.process.OutputAnalyzer.shouldHaveExitValue(OutputAnalyzer.java:522) at JShellHeapDumpTest.launch(JShellHeapDumpTest.java:82) ... 7 more JavaTest Message: Test threw exception: java.lang.RuntimeException: Test ERROR java.lang.RuntimeException: Expected to get exit value of [0], exit value is: [1] JavaTest Message: shutting down test STATUS:Failed.`main' threw exception: java.lang.RuntimeException: Test ERROR java.lang.RuntimeException: Expected to get exit value of [0], exit value is: [1]
16-01-2025
Looks like the DeoptimizeObjectsALotThread is missing from this list (this is the list I checked for "known" JavaThreads) https://github.com/openjdk/jdk/blob/9c430c92257739730155df05f340fe144fd24098/src/hotspot/share/runtime/vmStructs.cpp#L1250 And also here it probably needs to be added : https://github.com/openjdk/jdk/blob/9c430c92257739730155df05f340fe144fd24098/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Threads.java#L196 } catch (Exception e) { throw new RuntimeException("Unable to deduce type of thread from address " + threadAddr + " (expected type JavaThread, CompilerThread, MonitorDeflationThread, AttachListenerThread," + " StringDedupThread, NotificationThread, ServiceThread or JvmtiAgentThread)", e); }
16-01-2025