I started running into the following issue after implementing JDK-8307408, which changes the arguments used to launch the debuggee.

sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java sometimes times out on aarch64. I'm mostly noting this issue on OSX, but suspect it may also sometimes happen in linux. Although the stack trace of the process varies, the following frames are always present when the process times out:

	at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.sender(VFrame.java:126)
	at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.javaSender(VFrame.java:156)
	at jdk.hotspot.agent/sun.jvm.hotspot.runtime.ThreadStackTrace.dumpStack(ThreadStackTrace.java:54)
	at jdk.hotspot.agent/sun.jvm.hotspot.utilities.HeapHprofBinWriter.dumpStackTraces(HeapHprofBinWriter.java:836)
	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:340)
	at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:500)

It's actually stuck in VFrame.javaSender(). The issue is that no sanity check is done on the frame being looked at, so the following is at risk of getting stuck in an infinite loop if at some point what is suppose to be the sender frame is actually at a lower address instead of a higher address:

    VFrame f = sender(imprecise);
    while (f != null) {
      if (f.isJavaFrame()) {
        return (JavaVFrame) f;
      }
      f = f.sender(imprecise);
    }

The following code fixes the issue with an extra check:

    VFrame f = sender(imprecise);
    while (f != null) {
      if (f.isJavaFrame()) {
        return (JavaVFrame) f;
      }
      Address oldSP = f.getFrame().getSP();
      f = f.sender(imprecise);
      if (f != null) {
          Address newSP = f.getFrame().getSP();
          if (oldSP.greaterThanOrEqual(newSP)) {
              String errString = "newSP(" + newSP + ") is not above oldSP(" + oldSP + ")";
              System.out.println(errString);
              throw new RuntimeException(errString);
          }
      }
    }

Note this issue is very similar to JDK-8231635, but is different stack walking code. The difference is that the JDK-8231635 stack walking is using Frame.sender() and here we using VFrame.sender(). I'm not too clear on the distinction between these two different approaches to stack walking. In any case, the JDK-8231635 fix is similar to what I'm suggesting here, which is to santity check that sender frames are always at a higher address.