On Mon, 2 Sep 2024 10:29:40 GMT, Yasumasa Suenaga <ysuen...@openjdk.org> wrote:
>> I attempted to check stack trace in the core generated by [SEGV example in >> upcall](https://github.com/YaSuenag/garakuta/blob/841452d9176dab1ddbb552009c180530eb81190b/NativeSEGV/ffm/upcall/src/main/java/com/yasuenag/garakuta/nativesegv/upcall/Main.java) >> with `jhsdb jstack`, however it failed with following exception. >> >> >> Error occurred during stack walking: >> java.lang.RuntimeException: Couldn't deduce type of CodeBlob >> @0x00007fa04c265990 for PC=0x00007fa04c265aa6 >> at >> jdk.hotspot.agent/sun.jvm.hotspot.code.CodeCache.findBlobUnsafe(CodeCache.java:124) >> at >> jdk.hotspot.agent/sun.jvm.hotspot.code.CodeCache.findBlob(CodeCache.java:83) >> at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.cb(Frame.java:119) >> at >> jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.adjustUnextendedSP(X86Frame.java:334) >> at >> jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.initFrame(X86Frame.java:137) >> at >> jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.<init>(X86Frame.java:163) >> at >> jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.senderForInterpreterFrame(X86Frame.java:361) >> at >> jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.sender(X86Frame.java:281) >> 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:144) >> 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) >> Caused by: sun.jvm.hotspot.types.WrongTypeException: No suitable match for >> type of address 0x00007fa04c265990 (nearest symbol is _ZTV10Upcall... > > Yasumasa Suenaga has updated the pull request incrementally with three > additional commits since the last revision: > > - Update test/hotspot/jtreg/serviceability/sa/LingeredAppWithFFMUpcall.java > > Co-authored-by: Andrey Turbanov <turban...@gmail.com> > - Update test/hotspot/jtreg/serviceability/sa/LingeredAppWithFFMUpcall.java > > Co-authored-by: Andrey Turbanov <turban...@gmail.com> > - Update test/hotspot/jtreg/serviceability/sa/LingeredAppWithFFMUpcall.java > > Co-authored-by: Andrey Turbanov <turban...@gmail.com> test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackUpcall.java line 49: > 47: * Test should focus JNI call (caller of upcall) because the frame > 48: * prior to the upcall cannot be obtained if some exception happens > 49: * in during to process upcall. 2 questions here. Shouldn't we also check for the java frame that the upcall was mode to. 2nd is why are we worried about an exception here. test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackUpcall.java line 51: > 49: * in during to process upcall. > 50: */ > 51: private static boolean isJNIFrame(List<String> lines) { I think this method could use a better name like hasFFMUpcall(). test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackUpcall.java line 57: > 55: > 56: private static void runJstackInLoop(LingeredApp app) throws Exception > { > 57: for (int i = 0; i < MAX_ITERATIONS; i++) { What is the reason for doing 20 iterations. Is it because you are waiting for THREAD_NAME to enter the sleep() call? If so, we've addressed this in the past for the general case of wanting to do a "stable"stack trace by using the LingeredApp's SteadyStateThread. LingeredApp.startApp() will not return until this thread has become stable (blocked). Maybe you can do something similar with THREAD_NAME. test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackUpcall.java line 76: > 74: out.shouldContain(LingeredAppWithFFMUpcall.THREAD_NAME); > 75: if (isJNIFrame(out.asLines())) { > 76: System.out.println("DEBUG: Test triggered interesting > condition."); I'm not so sure what is meant by "intersting condition". Perhaps you mean "detected FFM upcall" or something like that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20789#discussion_r1742592058 PR Review Comment: https://git.openjdk.org/jdk/pull/20789#discussion_r1742590621 PR Review Comment: https://git.openjdk.org/jdk/pull/20789#discussion_r1742584621 PR Review Comment: https://git.openjdk.org/jdk/pull/20789#discussion_r1742588694
