JDK-4985017 : (process) Process.waitFor waits for subprocess IO to complete
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: 1.4.2
  • Priority: P3
  • Status: Closed
  • Resolution: Not an Issue
  • OS: windows_2000
  • CPU: x86
  • Submitted: 2004-01-28
  • Updated: 2006-12-04
  • Resolved: 2006-08-15
Related Reports
Relates :  
Relates :  
Description
Name: rl43681			Date: 01/28/2004


FULL PRODUCT VERSION :
java version "1.4.1"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1-b21)
Java HotSpot(TM) Client VM (build 1.4.1-b21, mixed mode)
and
java version "1.4.2_03"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_03-b02)
Java HotSpot(TM) Client VM (build 1.4.2_03-b02, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows 2000 [Version 5.00.2195]

A DESCRIPTION OF THE PROBLEM :
Runtime.exec() to start a new java program. The new java program should create a socket connection to another program.

The socket will connect if created and used from the static main method. It will also work if placed in a static method called from main. It will not work if I create an object and have the object execute the same code (which is what I need); it fails both times if the method is static or not static.

If I run the java program from the command line and not by using Runtime.exec, it works beautifully.

If while it is blocking I kill the first vm, then the second vm continues.


ACTUAL -
Blocking

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
public class ProgA {
	public static void main(String[] args) throws Exception {
		Runtime rt = Runtime.getRuntime();
		Process p = rt.exec("java ProgB");
		p.waitFor();
		System.out.println("Process Returned");
	}
}

///////////////////////////////////////////////////////////////////////

import java.net.*;
import java.io.*;

public class ProgB {

  public void service() throws Exception {
    //If I move this body of code to main or another static method,
    //the program works.
    Socket s = new Socket("127.0.0.1",  5000); //Blocking
    OutputStream o = s.getOutputStream();
    o.write("test data".getBytes() );
    s.close();
  }

  public static void main(String[] args) throws Exception {
    ProgB b = new ProgB();
    b.service();
  }
}


---------- END SOURCE ----------
(Incident Review ID: 229305) 
======================================================================

Comments
WORK AROUND For each stream that may possibly be written to by the child, the parent process must either: - set up a thread to read from that input stream, or - close that input stream.
15-08-2006

EVALUATION I don't know why I couldn't reproduce this on Windows, but on further reflection it is obvious that this is the old pipe buffer overflow hang problem. Sorry, this is Working As Designed, and is a problem that occurs in all languages that allow bidirectional I/O between two processes over pipes, on both Unix and Windows. Here is a much simpler program, that hangs even on Solaris unless the two lines are uncommented. public class Bug { public static void main(String[] args) throws Exception { if (args.length == 1 && args[0].equals("child")) { String xs = "X"; for (int i = 0; i < 14; i++) xs = xs + xs; System.out.println(xs); } else { Runtime rt = Runtime.getRuntime(); Process p = rt.exec(new String[] {"java", "Bug", "child"}); // p.getErrorStream().close(); // p.getInputStream().close(); p.waitFor(); } } } As I wrote elsewhere, Consider this extract from "man perlfunc" pipe READHANDLE,WRITEHANDLE Opens a pair of connected pipes like the corresponding system call. Note that if you set up a loop of piped processes, deadlock can occur unless you are very careful.
15-08-2006

EVALUATION I can't reproduce this on my Windows 2000 system. On 1.4.2, 5.0 and 6, Process Returned is always printed, although it might take a minute to do so. So currently this is Not Reproducible. Perhaps the networking team could explain why it takes such a long time. Since I don't have any socket expertise, I am redispatching to classes_net
10-08-2006