United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-4811767 (process) Runtime.exec should throw IOException when workdir does not exist (Unix)
JDK-4811767 : (process) Runtime.exec should throw IOException when workdir does not exist (Unix)

Details
Type:
Bug
Submit Date:
2003-02-03
Status:
Resolved
Updated Date:
2006-04-14
Project Name:
JDK
Resolved Date:
2006-04-14
Component:
core-libs
OS:
solaris,solaris_8,solaris_7
Sub-Component:
java.lang
CPU:
sparc
Priority:
P3
Resolution:
Fixed
Affected Versions:
1.3.0,1.4.2
Fixed Versions:

Related Reports
Duplicate:
Relates:
Relates:
Relates:
Relates:
Relates:
Relates:
Relates:

Sub Tasks

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

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
                                     
2003-11-06
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.
                                     
2006-03-17
EVALUATION

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



Hardware and Software, Engineered to Work Together