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

com.sun.tools.jdi.SunCommandLineLauncher.launch hangs if debugee VM produces too much output during VM startup

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: P3
    • Resolution: Won't Fix
    • Affects Version/s: 9
    • Fix Version/s: tbd
    • Component/s: core-svc
    • Labels:

      Description

      I think this might just be a more general issue of generating too much data at VM startup, but I'm currently seeing it with +PrintInterpreter. The debuggee hangs on a write() call after printing about 64k of interpreter assembly. write() blocked in a syscall, so I'm assuming its buffers are full and it's waiting for some reads to be done. Meanwhile on the debugger side, the java backtrace looks like:

      os_prio=0 tid=0x00007f85f8018800 nid=0x64da in Object.wait() [0x00007f85ffeca000]
         java.lang.Thread.State: WAITING (on object monitor)
         JavaThread state: _thread_blocked
      Thread: 0x00007f85f8018800 [0x64da] State: _at_safepoint _has_called_back 0 _at_poll_safepoint 0
         JavaThread state: _thread_blocked
      at java.lang.Object.wait(java.base/Native Method)
      - waiting on <0x00000006d6e8ad48> (a com.sun.tools.jdi.AbstractLauncher$Helper)
      at java.lang.Object.wait(java.base/Object.java:516)
      at com.sun.tools.jdi.AbstractLauncher$Helper.launchAndAccept(jdk.jdi/AbstractLauncher.java:188)
      - waiting to re-lock in wait() <0x00000006d6e8ad48> (a com.sun.tools.jdi.AbstractLauncher$Helper)
      at com.sun.tools.jdi.AbstractLauncher.launch(jdk.jdi/AbstractLauncher.java:132)
      at com.sun.tools.jdi.SunCommandLineLauncher.launch(jdk.jdi/SunCommandLineLauncher.java:225)
      at nsk.share.jdi.Binder.localDefaultLaunchDebugee(Binder.java:266)
      at nsk.share.jdi.Binder.bindToDebugeeNoWait(Binder.java:182)
      at nsk.share.jdi.Binder.bindToDebugee(Binder.java:237)
      at nsk.share.jdi.TestDebuggerType2.init(TestDebuggerType2.java:156)
      at nsk.share.jdi.TestDebuggerType2.runIt(TestDebuggerType2.java:192)
      at nsk.jdi.ThreadReference.forceEarlyReturn.forceEarlyReturn009.forceEarlyReturn009.run(forceEarlyReturn009.java:25)
      at nsk.jdi.ThreadReference.forceEarlyReturn.forceEarlyReturn009.forceEarlyReturn009.main(forceEarlyReturn009.java:17)

      As you can see this happened during the forceEarlyReturn009 test, but I'm assuming it's a more general problem. The debugger side has done some redirecting of the debuggee stdout/stderr. I haven't quite figured it all out yet. TestDebuggerType2.init() is a good place to start.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              cjplummer Chris Plummer
              Reporter:
              cjplummer Chris Plummer
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: