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)

FULL OPERATING SYSTEM VERSION : Linux Red Hat 7.3 (2.4 kernel)


A DESCRIPTION OF THE PROBLEM :
The Process object will not always return the correct exitStatus when running on Linux Red Hat v7.3. Other UNIX OSes seem to work fine.


The following code demonstrates the problem:


public class foo {
 public static void main(String args[]) {
  while(true) {
   try {
    Runtime runtime = Runtime.getRuntime();
    Process p = runtime.exec("/bin/false");
    p.waitFor();
    System.out.println("Exit status: " +  p.exitValue() );
   }catch(Exception e) {}
  }
 }
}



This code should always return 1, but the following output
shows what happens:


$ java foo
Exit status: 1
Exit status: 0
Exit status: 0
Exit status: 0
Exit status: 0
Exit status: 0
Exit status: 0
Exit status: 0
Exit status: 0
Exit status: 0
Exit status: 0
Exit status: 0
Exit status: 0
Exit status: 0
Exit status: 0
Exit status: 0
Exit status: 0
Exit status: 0
Exit status: 0
Exit status: 0
Exit status: 0
Exit status: 0
Exit status: 0
Exit status: 0
Exit status: 0
Exit status: 1
Exit status: 0
Exit status: 0
Exit status: 0
Exit status: 0
Exit status: 0
Exit status: 0
Exit status: 0
Exit status: 0
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 0
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 0
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 0
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 0
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 0
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
Exit status: 1
$


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. run the enclosed program


EXPECTED VERSUS ACTUAL BEHAVIOR :
if exitStatus of zero is printed, that's bad


REPRODUCIBILITY :
This bug can be reproduced often.

---------- BEGIN SOURCE ----------
public class foo {
 public static void main(String args[]) {
  while(true) {
   try {
    Runtime runtime = Runtime.getRuntime();
    Process p = runtime.exec("/bin/false");
    p.waitFor();
    System.out.println("Exit status: " +  p.exitValue() );
   }catch(Exception e) {}
  }
 }
}


---------- END SOURCE ----------

Release Regression From : 1.4
The above release value was the last known release where this 
bug was known to work. Since then there has been a regression.

(Review ID: 165615) 
======================================================================


 xxxxx@xxxxx  2002-12-09

Same bug has been reported by a CAP member:

J2SE Version (please include all output from java -version flag):
  J2SDK 1.4.1_01 and J2SDK 1.4.2 cap build 08

  Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_01-b01)
  Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-beta-b08)

Does this problem occur on J2SE 1.3 or 1.4?
  No.

  Not reproducable with JDK 1.3.1 and J2SDK 1.4.0:

  Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_06-b01)
  Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0_03-b04)

Operating System Configuration Information (be specific):
  Redhat Linux 8.0 with all errata up to Dec. 08 2002. Other platforms 
  untested so far.

Hardware Configuration Information (be specific):
  Athlon 1.2GHz, 512MB RAM, Geforce graphics adapter.


Bug Description:
  Process.waitFor() and Process.exitValue() incorrectly return 0 sometimes 
  (non-determistic) even if the exit value of the executed process is 
  always non-zero.

Steps to Reproduce (be specific):
  Run the attached program(ExitTest.java) on J2SDK 1.4.1 on J2SDK 1.4.2 
  build08 and observe the output. The attached program starts "/bin/mv" 
  without arguments 1000 times (sequentially) and checks the return code. 
  It reports how many times zero was incorrectly returned as the exit value.

Test program:(ExitTest.java)

  public class ExitTest
  {
	public static void main(String[] args) throws Throwable
	{
		int wrongExitCodes = 0;
		for (int i = 0; i < 1000; i++)
		{
			Process p = Runtime.getRuntime().exec("/bin/mv");
			int exitCode = p.waitFor();
			exitCode = p.exitValue();
			if (exitCode == 0)
				wrongExitCodes++;
		}
		System.out.println("wrong exit code count: "+wrongExitCodes);
	}
  }

Test result:

  Sample output with J2SDK 1.4.1_01 (WRONG):

  wrong exit code count: 137

  Sample output with J2SDK 1.4.0_03 (CORRECT):

  wrong exit code count: 0

Sleep for a few milliseconds (just one often works) in the child process.

--  xxxxx@xxxxx  2002/11/26

HotSpot installs a handler for SIGCHLD which reaps child processes, discarding
their exit status.  If the timing is right then this signal handler will reap
the child before the java.lang.Process reaper thread does, causing an exit
value of zero to be reported regardless of the actual value.  Whether or not
the HotSpot SIGCHLD handler can be overridden or fixed is under investigation.

--  xxxxx@xxxxx  2002/11/26

A few experiments show that in fact the SIGCHLD handler is never invoked for
child threads, just for child processes.  According to  xxxxx@xxxxx , all
threads created on Linux are children of the pthread library's manager thread,
and SIGCHLD signals for threads are delivered to the manager thread only.

This bug will be fixed by changing the Linux process code to install its own
trivial SIGCHLD handler, overriding the HotSpot handler.  A P4 cleanup bug
(4785154) has been filed against the HotSpot runtime system to remove the
current SIGCHLD logic since it doesn't serve any real purpose.

--  xxxxx@xxxxx  2002/11/26

Work-around:
Simply encapsluate command to execute in shell script:

cat >command.safe
/bin/true
/bin/true
exec command
EOF
chmod u+x command.safe

/bin/true might be any executable and there must be >= 2 
them (2 is enough).

Now is safe to execute 
  int err = 
java.lang.Runtime.getRuntime().exec("command.safe").waitFor();

This bug has resurfaced. I ran the example code above and
I'am getting both 1 and 0s with j2sdk1.4.1_02. When run with
1.4.0, it only prints 1's as expected.

linux kernel 2.4.19.  

4763362 is marked 'closed' because it is fixed
in the 1.4.2 release (code name mantis).

The J2SE 1.4.2 beta program is under way, and you can download
the latest from this web page:
    http://java.sun.com/j2se/1.4.2/download.html

For more information on 1.4.2, check these documents:
    http://java.sun.com/j2se/1.4.2/changes.html
    http://java.sun.com/j2se/1.4.2/relnotes.html

If you require that 4746255 be fixed in 1.4.1_xx or some earlier
release, you will need to get in touch with your paid Sun
support contact and ask for an escalation of 4763362

My Mistake. It seems to be working.

This bug is still present in 1.4.2Beta on RedHat Linux 9.
Linux Kernel 2.4.20-9

I encounterred similar problem. I'm using JDK 1.4.1 and Redhat 
8.0. In my code, I execute command "scp2 -B -q sourcefile 
userid@host:destinationfile". When I provide a wrong userid, 
the program sometimes returns success status: 0. It should 
always be some other value to indicate the error. I tried JDK 
1.4.2 beta, I still had same result. This problem never happen 
in Windows platform. scp2 is a utility program similar to rcp. It 
copies files between computers in a secure manner.

I am getting this problem with JDK 1.4.2_04 and 
RedHat Linux 9.0