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

setting a jdb breakpoint that is immediately hit produces confusing output

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Open
    • Priority: P4
    • Resolution: Unresolved
    • Affects Version/s: 11, 12
    • Fix Version/s: tbd
    • Component/s: core-svc
    • Labels:
      None

      Description

      If you set a breakpoint in a running program and hit that breakpoint right away, that output is somewhat confusing:

      class Hello {
          public static void main(String[] args) {
              while (true) {
                  int x = 1;
              }
          }
      }

      $ jdb Hello
      Initializing jdb ...
      > stop at Hello:4
      Deferring breakpoint Hello:4.
      It will be set after the class is loaded.
      > run
      run Hello
      Set uncaught java.lang.Throwable
      Set deferred uncaught java.lang.Throwable
      >
      VM Started: Set deferred breakpoint Hello:4

      Breakpoint hit: "thread=main", Hello.main(), line=4 bci=0
      4 int x = 1;

      main[1] clear Hello:4
      Removed: breakpoint Hello:4
      main[1] cont
      > stop at Hello:4

      Breakpoint hit: "thread=main", Hello.main(), line=4 bci=0
      Set breakpoint Hello:4
      4 int x = 1;

      main[1] main[1]

      You can see what appears to be an extra main[1] pompt. I noticed that the it does not always appear on the last line of output. Sometimes it comes sooner. Then I realized, as you can see above, that the "Set breakpoint" output that is the result of the "stop at" command is being printed after the "Breakpoint hit:" message. If jdb printed the "Set breakpoint" output and prompt before actually setting the breakpoint, you would properly see:

      > stop at Hello:4
      Set breakpoint Hello:4
      > Breakpoint hit: "thread=main", Hello.main(), line=4 bci=0
      4 int x = 1;

      main[1]

      In this case the first main[1] prompt is instead a simple > prompt, and happens before the "Breakpoint hit:" message. If possible, we should make it so all the output of the "stop at" command is produced before actually setting the breakpoint.

        Attachments

          Activity

            People

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

              Dates

              • Created:
                Updated: