Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8234197

ClhsdbCDSJstackPrintAll.java fails with "java.lang.RuntimeException: 'Java Stack Trace for main' missing from stdout/stderr"


    • Type: Bug
    • Status: Open
    • Priority: P3
    • Resolution: Unresolved
    • Affects Version/s: 14
    • Fix Version/s: tbd
    • Component/s: hotspot
    • Subcomponent:
    • CPU:
    • OS:


      serviceability/sa/ClhsdbCDSJstackPrintAll.java failed with:

      java.lang.RuntimeException: Test ERROR java.lang.RuntimeException: 'Java Stack Trace for main' missing from stdout/stderr

      at ClhsdbCDSJstackPrintAll.main(ClhsdbCDSJstackPrintAll.java:118)
      at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
      at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
      at java.base/java.lang.reflect.Method.invoke(Method.java:564)
      at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
      at java.base/java.lang.Thread.run(Thread.java:833)
      Caused by: java.lang.RuntimeException: 'Java Stack Trace for main' missing from stdout/stderr
      at jdk.test.lib.process.OutputAnalyzer.shouldMatch(OutputAnalyzer.java:306)
      at ClhsdbLauncher.runCmd(ClhsdbLauncher.java:149)
      at ClhsdbLauncher.run(ClhsdbLauncher.java:197)
      at ClhsdbCDSJstackPrintAll.main(ClhsdbCDSJstackPrintAll.java:114)
      ... 6 more

      For some reason the actual stack dump for the main thread was omitted from the clhsdb output, even though it was attempted. When the test passes, you'll see something like the following in the output:

      hsdb> Thread 1 Address: 0x000000040ad36000

      Java Stack Trace for main
      Thread state = BLOCKED
       - public static native void sleep(long) @0x0000000800133078 @bci = 0, pc = 0x000000041b8f2f37 (Interpreted)

       - public static void main(java.lang.String[]) @0x0000000454fc3d70 @bci = 54, line = 501, pc = 0x000000041b8ea3e8 (Interpreted)

      Thread 8 Address: 0x0000000454860800

      Java Stack Trace for Reference Handler

      Thread 1 is always main, followed by thread 8 which is always Reference Handler. This is on windows. It's different on linux. For this failed case you see:

      hsdb> Thread 1 Address: 0x0000006e24f06000
      Thread 8 Address: 0x0000006e6ea48000

      Java Stack Trace for Reference Handler

      So there is no information printed for Thread 1 other than its address. The SA code that is controlling the output for this part of the test is for the "where -a" command which is implemented in CommandProcessor.java. In particular:

                          for (int i = 0; i < threads.getNumberOfThreads(); i++) {
                              JavaThread thread = threads.getJavaThreadAt(i);
                              ByteArrayOutputStream bos = new ByteArrayOutputStream();
                              thread.printThreadIDOn(new PrintStream(bos));
                              if (all || bos.toString().equals(name)) {
                                  out.println("Thread " + bos.toString() + " Address: " + thread.getAddress());
                                  HTMLGenerator gen = new HTMLGenerator(false);
                                  try {
                                  } catch (Exception e) {
                                      err.println("Error: " + e);
                                      if (verboseExceptions) {
                                  if (!all) return;

      So we see that the code that prints the "Address" is succeeding, but the call genHTMLForJavaStackTrace() must be producing an exception, because the first thing it does is:

            buf.append("Java Stack Trace for ");

      which we never see. After this it walks the stack, which is where the exception is likely happening. I do see the "Error:" in the output, although immediately before the "Address" line for main:

      Error: java.lang.IndexOutOfBoundsException: Index 0 out of bounds for length 0
       stdout: [ Thread 1 Address: 0x0000006e24f06000
      Thread 8 Address: 0x0000006e6ea48000

      I think it is appearing on stderr whereas the "Address" line is on some other output stream that isn't printed until later, thus the output is out of order here.

      So looks like an exception while walking the main thread stack has resulted in no stack output for the main thread. It looks like verboseExceptions in CommandProcessor needs to be enabled to get full stack trace of the exception. I think this can be done simply by sending a "verbose true" command:

              new Command("verbose", "verbose true | false", true) {
                  public void doit(Tokens t) {
                      if (t.countTokens() != 1) {
                      } else {
                          verboseExceptions = Boolean.valueOf(t.nextToken()).booleanValue();

      So the test should be modified to do the following to get more information on why the stack walking is failing:

       - cmds = List.of("jstack -v", "printall", "where -a");
       + cmds = List.of("jstack -v", "printall", "verbose true", "where -a");

      Unfortunately this this bug seems to be very rare.


          Issue Links



              • Assignee:
                cjplummer Chris Plummer
              • Votes:
                0 Vote for this issue
                1 Start watching this issue


                • Created: