JDK-4811767 : (process) Runtime.exec should throw IOException when workdir does not exist (Unix)
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: 1.3.0,1.4.2
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris,solaris_7,solaris_8
  • CPU: sparc
  • Submitted: 2003-02-03
  • Updated: 2006-04-14
  • Resolved: 2006-04-14
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6
6 b81Fixed
Related Reports
Duplicate :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Description
Runtime.Exec() freeze when we specify non-exist directory in arg list.

REPRODUCE:
 1. Compile the below program

===>
import java.io.*;
public class Exec {
    public static void main( String argv[] ) {
        try {
            File path = new File("/export/home/java/nosuchdir");
                           // Specify non-exist dir.
            Process process = Runtime.getRuntime().exec( argv, null, path );

            BufferedReader br = new BufferedReader(
                new InputStreamReader(
                    process.getInputStream() ) );
            String line;
            while( (line = br.readLine()) != null )
                System.out.println( line );

        }
        catch( IndexOutOfBoundsException e ) {
            System.err.println( "Usage:java ExecTest command [args...]" );
            System.exit(-1);
        }
        catch( Exception e ){
            System.err.println( "Error:" + e.toString() );
            System.exit(-1);
        }
    }
}
<===

 2. Launch the "java Exec ls"
    (This command line try to "ls" command under the specified directory)

  Here, no response returns.


Note:
  - When the non-exist directory is specified, an exception should be thrown
    freeze should not occur.
  - When existing directory is specified, the "ls" command is execute 
    correctly.


CONFIGRATION:
   OS : Solaris 7, 8
   JDK: 1.4.1-b21/1.4.2-beta-b13
   

===========================================================================

Comments
EVALUATION The fix for 4052517: (process) Solaris Runtime.exec won't execute programs belonging to other groups makes it easy to fix this properly.
10-04-2006

EVALUATION When the dir argument to Runtime.exec() does not exist: - 1.4.2 Solaris hangs - 5.0 prints a message on stderr (where no one might see it) and always exits with an exitValue of -1 (aka 255), as a result of the changes for 4790606: (process) Native forkAndExec code should be unified (sol, lnx) The proper behavior is to throw an IOException. Changing the synopsis to match the problem in the latest code.
17-03-2006

EVALUATION Reproducible on solaris, jdk1.3 - jdk1.4.2-beta-b15. On linux, if the test is modified to display stderr, the error message from the subprocess is displayed and the program properly exits. Based on the following thread dump, it appears that an exit code has not been detected/sent. $ java Exec ls ^\Full thread dump Java HotSpot(TM) Client VM (1.4.2-beta-b15 mixed mode): "process reaper" daemon prio=5 tid=0x000eafb0 nid=0xb runnable [f9681000..f96819a0] at java.lang.UNIXProcess.waitForProcessExit(Native Method) at java.lang.UNIXProcess.access$800(UNIXProcess.java:17) at java.lang.UNIXProcess$3.run(UNIXProcess.java:79) "Signal Dispatcher" daemon prio=10 tid=0x000c2f20 nid=0x8 waiting on condition [0..0] "Finalizer" daemon prio=8 tid=0x000bf418 nid=0x6 in Object.wait() [fc381000..fc3819a0] at java.lang.Object.wait(Native Method) - waiting on <0xf1400490> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:111) - locked <0xf1400490> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:127) at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159) "Reference Handler" daemon prio=10 tid=0x000bdaf0 nid=0x5 in Object.wait() [fde81000..fde819a0] at java.lang.Object.wait(Native Method) - waiting on <0xf1400380> (a java.lang.ref.Reference$Lock) at java.lang.Object.wait(Object.java:429) at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:113) - locked <0xf1400380> (a java.lang.ref.Reference$Lock) "main" prio=5 tid=0x0002d290 nid=0x1 runnable [ffbed000..ffbedf0c] at java.io.FileInputStream.readBytes(Native Method) at java.io.FileInputStream.read(FileInputStream.java:194) at java.io.BufferedInputStream.read1(BufferedInputStream.java:220) at java.io.BufferedInputStream.read(BufferedInputStream.java:277) - locked <0xf141d728> (a java.io.BufferedInputStream) at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:408) at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:450) at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:182) - locked <0xf141e1c8> (a java.io.InputStreamReader) at java.io.InputStreamReader.read(InputStreamReader.java:167) at java.io.BufferedReader.fill(BufferedReader.java:136) at java.io.BufferedReader.readLine(BufferedReader.java:299) - locked <0xf141e1c8> (a java.io.InputStreamReader) at java.io.BufferedReader.readLine(BufferedReader.java:362) at Exec.main(Exec.java:13) "VM Thread" prio=5 tid=0x000bccc0 nid=0x4 runnable "VM Periodic Task Thread" prio=10 tid=0x000df288 nid=0xa waiting on condition "Suspend Checker Thread" prio=10 tid=0x000c25b8 nid=0x7 runnable -- iag@sfbay 2003-02-03 Due to other changes in the implementation of J2SE 1.5, the sample program no longer hangs. Instead the exec simply returns, which is arguably an improvement. However, as the submitter correctly points out, an exception should be thrown. The correct solution is to add another communication mechanism between parent and child process so that in case of an exec error, the child can communicate the nature of the failure back to the parent, and a proper exception can be thrown. This will likely not happen for 1.5. ###@###.### 2003-11-06
06-11-2003