JDK-4368399 : JDI: -verbose option passed to debugger launcher fails and hangs vm
  • Type: Bug
  • Component: core-svc
  • Sub-Component: debugger
  • Affected Version: 1.3.0,5.0,8,9
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: solaris_8,windows_nt
  • CPU: x86,sparc
  • Submitted: 2000-09-05
  • Updated: 2018-11-16
  • Resolved: 2016-11-03
Related Reports
Duplicate :  
JDK-4905551 - JDI: shmemBase_listen failed: Cannot create a file when that file already exists
Relates :  
JDK-8173304 - com.sun.tools.jdi.SunCommandLineLauncher.launch hangs if debugee VM produces too much output during VM startup
Relates :  
JDK-4210128 - Running a process from JVM hangs JVM and Process . both.
Relates :  
JDK-4098442 - Process.waitFor() fails to return
Relates :  
JDK-4362594 - JDWP: Need a way to send output and error streams to debugger
Relates :  
JDK-4254231 - Process.waitFor() fails to return - still a bug - 4098442 is NOT fixed!
Relates :  
JDK-4428270 - JDI: Unable to launch a debugee program with vmexec=java_g
Relates :  
JDK-4367942 - Stopping a HotSpot debug session leaves behind a javaw.exe.
Description

Name: pa48320			Date: 09/05/2000

Two related problems:
1. can't pass -verbose to debugger vm
2. debugger vm throws an exception on invalid options but doesn't terminate the VM or return control to the caller.

I'm running JDK1.3.0-C

I'm trying to start the debugger with a command-line argument that it doesn't like and I don't believe I've doing anything wrong.

What I want to do is pass a verbose flag to the debug VM.  On the LaunchingConnector, I get the arguments, request the "options" arg and add -verbose:class to my string.  I successfully have other arguments in my string such as -Xmx64000000.  But when I add a verbose flag, I get the following exception (and you can see my full command line here as well):

com.sun.jdi.connect.VMStartException: VM initialization failed for: C:\jdk1.3\bin\javaw -classic -Xmx128000000 -Xms128000000 -classpath c:\appdevstudio\webAF\Projects\ConsoleTest;c:\playpen;C:\AppDevStudio\webEIS\webeisapp.jar;C:\AppDevStudio\webAF\Projects\lib; -verbose:class -Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_shmem,address=javadebug,suspend=y ConsoleTest
	at com.sun.tools.jdi.AbstractLauncher$Helper.launchAndAccept(AbstractLauncher.java:168)
	at com.sun.tools.jdi.AbstractLauncher.launch(AbstractLauncher.java:109)
	at com.sun.tools.jdi.SunCommandLineLauncher.launch(SunCommandLineLauncher.java:142)
	at com.sas.sdi.RemoteDebugger.startDebuggingApplication(RemoteDebugger.java:173)

Also, when I get this failure the VM continues to run and I don't get a response back from the "launch".  So the VM hangs around until I kill it with TaskManager.

Am I missing something here?

Thanks,
Ernest

======================================================================
Comments
Hmm. When I last looked at the CR around 2017-05-16, it had a design-notes document attached to it that listed 4 possible solutions. For some reason that document no longer seems to be attached, nor are some discussion emails that also were attached at one point.
16-11-2018
I'm not sure why the nsk/jdi/ListeningConnector/stopListening/stoplis002 RULE was added. It is completely unrelated to the issue. The problem described here is the debugee is filling up the stdout or stderr buffer during startup, and the debugger is waiting for startup to complete before it starts reading from either. This is the same issue I brought up in the following CR: JDK-8173304: com.sun.tools.jdi.SunCommandLineLauncher.launch hangs if debugee VM produces to much output during VM startup
16-05-2017
This is not on our list of current priorities, if this changes please re-open this issue.
03-11-2016
EVALUATION tim.bell@Eng 2001-04-18 Preliminary evaluation: The following options work OK: -connect com.sun.jdi.CommandLineLaunch:vmexec=java_g,main=HelloWorld -connect com.sun.jdi.CommandLineLaunch:options=-verbose:jni,main=HelloWorld The following fails: -connect com.sun.jdi.CommandLineLaunch:options=-verbose:class,main=HelloWorld The debugee process starts up but then hits a deadlock/hang. If you send the debugee a "kill -QUIT <pid>" signal, you will then see the first few screenfulls of the verbose:class output, followed by "Target VM failed to initialize." The difference between "-verbose:jni" and "-verbose:class" seems to be the volume of output generated. My hypothesis is that some buffer is filling up and causing the deadlock/hang. ###@###.### 2001-08-24 The com.sun.jdi.CommandLineLaunch connector uses process = Runtime.getRuntime().exec(commandArray); to start up the debugee as a subprocess. It then gets the stdout and stderr streams from the java.lang.Process object and starts reading output from them. Quoting from the javadoc for java.lang.Process: http://java.sun.com/j2se/1.3/docs/api/java/lang/Process.html The Runtime.exec methods may not work well for special processes on certain native platforms, such as native windowing processes, daemon processes, Win16/DOS processes on Win32, or shell scripts. The created subprocess does not have its own terminal or console. All its standard io (i.e. stdin, stdout, stderr) operations will be redirected to the parent process through three streams (Process.getOutputStream(), Process.getInputStream(), Process.getErrorStream()). The parent process uses these streams to feed input to and get output from the subprocess. Because some native platforms only provide limited buffer size for standard input and output streams, failure to promptly write the input stream or read the output stream of the subprocess may cause the subprocess to block, and even deadlock. Exactly what is happening in this case. The debugee VM immediately starts writing "-verbose" output to stdout. If there is a lot of output (as in the case of "-verbose:class") the buffer fills up before the debugger can capture the stream and start reading from it. The debugee (subprocess) is blocked and we are left with a deadlock because the debugger is waiting inside an accept() call for something that cannot be delivered until the debugee is restarted. See workaround and Bug IDs 4098442, 4254231, 4210128 ###@###.### 2001-09-19 A bit more analysis: The debugger launches the debugee process via Runtime.getRuntime().exec(commandArray); [AbstractLauncher.java line 156] It then starts two threads (acceptingThread, monitoringThread) to monitor progress of the debugee. Then the debugger goes into a wait() until the debugee finishes starting up and completes the JDI handshake. [AbstractLauncher.java line 164] The debugee starts up and immediately writes the -verbose:class output. to stdout. This output fills up the stdout buffer (and the debugee is blocked) long before the debugee starts it's half of the JDI connection. We are left with the debugee blocked and the debugger waiting for a notify() that will never arrive. One proposed solution (requires an API change): Modify the LaunchingConnector interface so that the launch() method is broken down into two parts, perhaps create() and start(). This would allow the debugger to do the create(), then access the debugee process object (for example to attach listeners on the stdout and stderr streams), and then, when everything is ready, use start() to set the debugee running and commence the JDI session. ###@###.### 2003-08-26 This bug was discussed during the evaluation of: 4905551 3/1 JDI: shmemBase_listen failed: Cannot create a file when that file already exists I have attached the relevant e-mail messages in design-notes.
21-07-2004
WORK AROUND Name: pa48320 Date: 09/05/2000 No work around known. ====================================================================== ###@###.### 2001-08-23 To bypass this conflict, separate debugger and debugee. Start the debugee program in one command window: java -Xdebug -Xrunjdwp:transport=dt_socket,server=y,address=4571 -verbose:class HelloWorld In another window, attach your debugger (jdb in this example) to the debugee via a socket: jdb -connect com.sun.jdi.SocketAttach:hostname=localhost,port=4571 You may also use the shared memory transport if you are on a win32 platform, as follows: In one command window: java -Xdebug -Xrunjdwp:transport=dt_shmem,server=y,address=mine -verbose:class HelloWorld In a second command window (again using jdb as an example): jdb -connect com.sun.jdi.SharedMemoryAttach:name=mine
21-07-2004
PUBLIC COMMENTS .
21-07-2004