JDK-8317438 : serviceability/sa/ClhsdbInspect.java is transiently failing UnknownOopException on libgraal
  • Type: Bug
  • Component: hotspot
  • Sub-Component: svc-agent
  • Affected Version: 22
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2023-10-03
  • Updated: 2024-06-10
  • Resolved: 2023-10-06
Related Reports
Duplicate :  
JDK-8283578 - serviceability/sa/ClhsdbInspect.java is failing with various addressing errors
Relates :  
JDK-8293563 - [macos-aarch64] SA core file tests failing with sun.jvm.hotspot.oops.UnknownOopException
Description
We're seeing this error very rarely in libgraal testing (1 out of 184 executions):

Attaching to process 3042, please wait...
hsdb> hsdb> + verbose true
hsdb> + inspect 0x00000000d9488418
Error: sun.jvm.hotspot.oops.UnknownOopException: 0x00000000d9488418
sun.jvm.hotspot.oops.UnknownOopException: 0x00000000d9488418
	at jdk.hotspot.agent/sun.jvm.hotspot.oops.ObjectHeap.newOop(ObjectHeap.java:193)
	at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor$25.doit(CommandProcessor.java:1109)
	at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2212)
	at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:2182)
	at jdk.hotspot.agent/sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:2053)
	at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:112)
	at jdk.hotspot.agent/sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:44)
	at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runCLHSDB(SALauncher.java:281)
	at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:500)
hsdb> + quit
Comments
Thanks for the in-depth analysis and explanation [~cjplummer].
06-10-2023
This is a duplicate of JDK-8283578. The 0x00000000d9488418 oop address was gleaned from the following jstack output: "Thread-0" #20 prio=5 tid=0x00007f384c3ee4c0 nid=3248 waiting on condition [0x00007f3827827000] java.lang.Thread.State: TIMED_WAITING (sleeping) JavaThread state: _thread_blocked - java.lang.Thread.sleepNanos0(long) @bci=0, pc=0x00007f384122a328, Method*=0x00007f37e64ae458 (Compiled frame; information may be imprecise) - java.lang.Thread.sleepNanos(long) @bci=33, line=491, pc=0x00007f3840b6414e, Method*=0x00007f37e64ae4d8 (Interpreted frame) - java.lang.Thread.sleep(long) @bci=25, line=522, pc=0x00007f3840b6414e, Method*=0x00007f37e64ad9d8 (Interpreted frame) - LingeredAppWithLock.lockMethod(java.lang.Object) @bci=7, line=32, pc=0x00007f38412266d0, Method*=0x00007f37dc403630 (Compiled frame) - locked <0x00000000d9488418> (a java.lang.Class for LingeredAppWithLock) - LingeredAppWithLock.lambda$main$0() @bci=2, line=40, pc=0x00007f38412266d0, Method*=0x00007f37dc403ac8 (Compiled frame) - LingeredAppWithLock$$Lambda+0x00007f37e7001868.run() @bci=0, pc=0x00007f38412266d0, Method*=0x00007f37dc409b30 (Compiled frame) - java.lang.Thread.runWith(java.lang.Object, java.lang.Runnable) @bci=5, line=1583, pc=0x00007f38412230a4, Method*=0x00007f37e64af0c8 (Compiled frame) - java.lang.Thread.run() @bci=19, line=1570, pc=0x00007f38412230a4, Method*=0x00007f37e6019ff0 (Compiled frame) The problem is the test then detaches (allowing the debuggee to run) and then re-attaches to issue the inspect command. The object may have moved while SA was not attached, rendering the oop invalid. Fixing this will require some major restructuring of how the ClhsdbLauncher class works (it's a test utility class). Currently it does support executing a batch of commands while maintaining the connection, but it does not allow the test to look at the output of a command (or commands) and then issues more commands without detaching and then re-attaching. So whenever a test needs to glean an oop address out of the output and then do more clhsdb commands, it is at risk for this type of problem.
06-10-2023
Similar to JDK-8293563. Moving this to hotspot/svc for now.
03-10-2023