JDK-4362594 : JDWP: Need a way to send output and error streams to debugger
  • Type: Enhancement
  • Component: core-svc
  • Sub-Component: debugger
  • Affected Version: 1.3.0,5.0
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: generic,solaris_7
  • CPU: generic,sparc
  • Submitted: 2000-08-15
  • Updated: 2016-11-03
  • Resolved: 2016-11-03
Related Reports
Duplicate :  
JDK-4641616 - JDWP: Need a way to send output and error streams to debugger
Duplicate :  
JDK-4446286 - Println message is not reflected to remote debugging machine
Relates :  
JDK-4368399 - JDI: -verbose option passed to debugger launcher fails and hangs vm
Relates :  
JDK-4533879 - Enhance remote debugging
Relates :  
JDK-4492918 - TTY: debugee output not seen until a newline is written
Description
With the old jdb/sun.tools.debug remote debugging the standard output
and error streams in the VM/agent were redirected to the socket
connection to the debugger. This was a very useful feature (perhaps
side effect) as it allowed a tty debugger to print the output and 
error streams to the console in the debugger.

JDWP uses a structured message exchange between the debugger and
debuggeer and the protocol doesn't appear to allow a streams to
be encapsulated and thus it doesn't appear to be possible to
redirect output and error streams to the debugger.

This RFE is to support redirecting of output and error streams
to the debugger. This is only applicable to the socket transport
at this time. It may be necessary to use an additional socket
connection rather than stretching the JDWP protocol. 

In implementation terms the socket transport could support a
redirectoutput={y,n} option and if so it connects to a socket
that the debugger has binded too. On the debugger side a thread
could bind to a port and wait for messages to arrive. With a
tty debugger these messages could be printed to the console. 
In a graphical debugger these could be displayed in an output
window.
Comments
This is not on our list of current priorities, if this changes please re-open this issue.
03-11-2016
SUGGESTED FIX Below is an example debugger written using JDI which captures the stdout and stderr output of the debugee and displays it. If you supply the command line parameter "-output /tmp/foo.txt", the SimpleDebugger example will write the debugee output into that file instead of forwarding it to its own stdout. (Excerpted below) /* * Catch and redisplay stdout and stderr of the target process. */ Process process = vm.process(); displayRemoteOutput(process.getErrorStream(), writer); displayRemoteOutput(process.getInputStream(), writer); ..... /** * Create a Thread that will retrieve and display any output. * Needs to be high priority, else debugger may exit before * it can be displayed. */ private void displayRemoteOutput(final InputStream stream, final PrintWriter writer) { Thread thr = new Thread ("output reader") { public void run() { try { dumpStream(stream, writer); } catch(IOException ex) { System.err.println("Failed reading output of child java interpreter."); } finally { try { stream.close(); } catch(IOException ex) { // SKIP } } } }; thr.setPriority(Thread.MAX_PRIORITY - 1); thr.start(); } private void dumpStream(InputStream stream, PrintWriter writer) throws IOException { BufferedReader in = new BufferedReader(new InputStreamReader(stream)); String line; while ((line = in.readLine()) != null) { writer.println(line); } }
11-06-2004
PUBLIC COMMENTS .
10-06-2004
EVALUATION begin - tim.bell@Eng 2000-09-07 I'm confused. Isn't this capability already available using the JDI interface? If the following does not clarify the functionality, please let me know. The jdb reference debugger can do it... After you compile the sample code below, you can demonstrate this with the following command line: % jdb Target $JAVA_HOME/README Initializing jdb... > run [...you will see the contents of $JAVA_HOME/README as written to stdout by the Target class...] Example using this in excerpted in Suggested Fix. end - tim.bell@Eng 2000-09-07 begin - tim.bell@Eng 2000-09-26 The following text and demo works fine if both the debugger and debugee processes are on the same machine. This cabability is lacking in the current JPDA version if the two are on separate machines. I am re-opening this report. end - tim.bell@Eng 2000-09-26 begin - robert.field@Eng 2001-04-23 What this is about -- if you use a launching connector, you can get the Process that was launched and from that get its in/out/err streams. This is what jdb does in a typical debugging situation. One is able to get the Process because the connector launched the process. So this does not work for other connectors. Launching connectors only work on the local machine. To do remote debugging (or use an attaching connector) you need to have a command port since there must be a mechanism to start the remote VM. This command port is then what is used for input and output. Although I can imagine scenarios where it would be convenient to have the back-end grab the streams, I would have to know more about why and what is needed. There are three levels at/to which this could be implemented. 1) There could be parameters to the launch of the back-end that would redirect the I/O to a socket. This however, could be achieved now by anyone with a wrapper around the VM launch. 2) The I/O could be redirected to sockets but with info communicated to or under the control of JDWP/JDI. This would then be limited to sockets. 3) The I/O could be packetized and sent interspersed with JDWP commands and events. This is the most general solution but introduces potential timing issues. Solutions 2) and 3) require additions to the JDI API and extensions to the JDWP protocol, the JDWP extensions having potential compatibility concerns. end - robert.field@Eng 2001-04-23
23-04-2001