On Tue, 21 Jan 2025 13:24:41 GMT, Matthias Baesken <mbaes...@openjdk.org> wrote:
> 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
>
> In the discussion in the JBS bug it was found that a retry option in` launch
> `should be added.
test/jdk/sun/tools/jhsdb/JShellHeapDumpTest.java line 84:
> 82: output.shouldHaveExitValue(0);
> 83: } catch (Exception ex) {
> 84: if (allowRetry) return false;
The exception should be printed if we are going to retry, and also maybe print
a message that mentions retrying similar to what we do in printStackTraces()L
122 System.out.println("'JShellToolProvider' missing. Allow
one retry.");
test/jdk/sun/tools/jhsdb/JShellHeapDumpTest.java line 104:
> 102: if (!res) { // try once more
> 103: launch(expectedMessage, Arrays.asList(toolArgs), false);
> 104: }
`launch()` should take an allowRetry argument and only retry if true. This test
is operated in two different modes. One is with an active target process and
one is with a target process that should be stabilized and inactive. The latter
is not allowed to retry since it should never fail. Also, it would help to add
a comment as to why the retry is being done. See the comment in
`printStackTrace()`.
I think a better approach would be for launch() to just return if a retry
should be done. testHeapDump() should check the result, and just immediately
return true if launch() returns true.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/23213#discussion_r1924239855
PR Review Comment: https://git.openjdk.org/jdk/pull/23213#discussion_r1924237704
