JDK-8173304 : com.sun.tools.jdi.SunCommandLineLauncher.launch hangs if debugee VM produces too much output during VM startup
  • Type: Bug
  • Component: core-svc
  • Sub-Component: debugger
  • Affected Version: 9
  • Priority: P3
  • Status: Resolved
  • Resolution: Won't Fix
  • OS: linux
  • Submitted: 2017-01-24
  • Updated: 2024-02-01
  • Resolved: 2019-06-21
Related Reports
Duplicate :  
JDK-8305420 - VMConnection.open blocks if child process has lots of output
Relates :  
JDK-4368399 - JDI: -verbose option passed to debugger launcher fails and hangs vm
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.
Comments
Another work around is to redirect logging output to a log file.
01-02-2024
Closing as WNF just like we decided for JDK-4368399. This is only a test issue when enabling certain debugging output. Does not seem worth the effort to attempt to fix.
21-06-2019
Looks like this problem was first reported 17 years ago in JDK-4368399, which is now closed as WNF. There are a number of fixes proposed in JDK-4368399. See the design-notes.Z document that is attached to it.
16-05-2017
I found that on Solaris and Windows, it seems to be an issue after just about 6k of debugee output on VM startup. Just turning on -XX:+PrintCompilation was enough to cause the problem.
14-02-2017