JDK-8339772 : serviceability/sa/TestJhsdbJstackUpcall.java fails on Linux ppc64le
  • Type: Bug
  • Component: hotspot
  • Sub-Component: svc-agent
  • Affected Version: 24
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: linux
  • CPU: ppc
  • Submitted: 2024-09-09
  • Updated: 2024-09-23
  • Resolved: 2024-09-23
Related Reports
Duplicate :  
JDK-8340657 - [PPC64] SA determines wrong unextendedSP
Relates :  
JDK-8339307 - jhsdb jstack could not trace FFM upcall frame
Description
We run into this error when running serviceability/sa/TestJhsdbJstackUpcall.java :

Error occurred during stack walking:
sun.jvm.hotspot.debugger.UnalignedAddressException: Trying to read at address: 0xfffffffffffffff3 with alignment: 8
	at jdk.hotspot.agent/sun.jvm.hotspot.debugger.DebuggerUtilities.checkAlignment(DebuggerUtilities.java:68)
	at jdk.hotspot.agent/sun.jvm.hotspot.debugger.DebuggerBase.readCInteger(DebuggerBase.java:349)
	at jdk.hotspot.agent/sun.jvm.hotspot.debugger.DebuggerBase.readAddressValue(DebuggerBase.java:382)
	at jdk.hotspot.agent/sun.jvm.hotspot.debugger.linux.LinuxDebuggerLocal.readAddress(LinuxDebuggerLocal.java:479)
	at jdk.hotspot.agent/sun.jvm.hotspot.debugger.linux.LinuxAddress.getAddressAt(LinuxAddress.java:73)
	at jdk.hotspot.agent/sun.jvm.hotspot.runtime.ppc64.PPC64Frame.<init>(PPC64Frame.java:110)
	at jdk.hotspot.agent/sun.jvm.hotspot.runtime.ppc64.PPC64Frame.senderForUpcallStub(PPC64Frame.java:334)
	at jdk.hotspot.agent/sun.jvm.hotspot.runtime.ppc64.PPC64Frame.sender(PPC64Frame.java:282)
	at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.sender(Frame.java:207)
	at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.realSender(Frame.java:212)
	at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.sender(VFrame.java:120)
	at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.javaSender(VFrame.java:150)
	at jdk.hotspot.agent/sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:81)
	at jdk.hotspot.agent/sun.jvm.hotspot.tools.StackTrace.run(StackTrace.java:45)
	at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.run(JStack.java:67)
	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.JStack.runWithArgs(JStack.java:90)
	at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJSTACK(SALauncher.java:302)
	at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:500)

"SteadyStateThread" #35 prio=5 tid=0x00007fff8c833240 nid=34450 waiting for monitor entry [0x00007fff366bd000]
   java.lang.Thread.State: BLOCKED (on object monitor)
   JavaThread state: _thread_blocked
 - jdk.test.lib.apps.LingeredApp.steadyState(java.lang.Object) @bci=8, line=567 (Interpreted frame)
	- waiting to lock <0x00000000ff84b190> (a jdk.test.lib.apps.LingeredApp$SteadyStateLock)
 - jdk.test.lib.apps.LingeredApp$1.run() @bci=4, line=573 (Interpreted frame)

];
 stderr: []
 exitValue = 0

java.lang.RuntimeException: 'LingeredAppWithFFMUpcall.callJNI' missing from stdout/stderr
	at jdk.test.lib.process.OutputAnalyzer.shouldContain(OutputAnalyzer.java:252)
	at TestJhsdbJstackUpcall.runJstack(TestJhsdbJstackUpcall.java:58)
	at TestJhsdbJstackUpcall.main(TestJhsdbJstackUpcall.java:75)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
	at java.base/java.lang.reflect.Method.invoke(Method.java:573)
	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333)
	at java.base/java.lang.Thread.run(Thread.java:1575)
java.lang.RuntimeException: 'LingeredAppWithFFMUpcall.callJNI' missing from stdout/stderr
	at jdk.test.lib.process.OutputAnalyzer.shouldContain(OutputAnalyzer.java:252)
	at TestJhsdbJstackUpcall.runJstack(TestJhsdbJstackUpcall.java:58)
	at TestJhsdbJstackUpcall.main(TestJhsdbJstackUpcall.java:75)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
	at java.base/java.lang.reflect.Method.invoke(Method.java:573)
	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333)
	at java.base/java.lang.Thread.run(Thread.java:1575)
Comments
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/21092 Date: 2024-09-19 14:52:07 +0000
19-09-2024
GCC with "-O0 -fPIC -shared -c" (or no -O flag) produces code which can't be analyzed properly by debuggers. GDB backtrace shows the following issue for a simple test which calls "nativeFun" via Upcall: #19 0x000074342504adac in ?? () #20 0x00007434391f021c in nativeFun () from TestUpcall.so Backtrace stopped: previous frame inner to this frame (corrupt stack?) Using an optimization (-O1, -O2 or -O3) solves the issue. GDB (and probably also the SA) can step over the native frame. Is this a GCC or binutils bug? Should we compile the test with some optimization turned on? Or just problem list the test?
16-09-2024