Bug 11801 - Problems with Process.waitFor() and exitValue()
Summary: Problems with Process.waitFor() and exitValue()
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: libgcj (show other bugs)
Version: 3.4.0
: P2 normal
Target Milestone: 4.0.0
Assignee: David Daney
URL:
Keywords:
: 12956 14709 (view as bug list)
Depends on:
Blocks:
 
Reported: 2003-08-05 05:04 UTC by Bryce McKinlay
Modified: 2004-08-12 17:51 UTC (History)
5 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2004-07-27 18:28:07


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Bryce McKinlay 2003-08-05 05:04:23 UTC
There are some bugs with libgcj's POSIX Runtime.exec implementation.

Problem #1: Process.exitValue() only returns the processes exit code if waitFor() has already been 
called, because only waitFor() ever calls waitpid.

Problem #2: Process.waitFor() and Process.exitValue() do not work if they are called from a thread 
other than the thread which called Runtime.exec().  This seems to be because the pid created in 
Runtime.exec() is only considered a child of the thread which created it.

Currently the problem can be hidden in some cases because Process.waitFor() will actually return 0 
if waitpid returns an error other than EINTR.

Possible solution: SIGCHLD handler?
Comment 1 Andrew Pinski 2003-08-05 05:21:47 UTC
I can confirm Problem 1.

Problem 2 sounds more like a Linux (Linux Threads or otherwise, glibc) problem rather than a 
libgcj problem as it will work fine on Darwin as threads are not processes in Darwin.
Comment 2 Bryce McKinlay 2003-08-05 05:51:29 UTC
Yes, it is presumably due to linux's 1:1 thread->pid mapping. I guess that POSIX does not specify 
how waitpid() should interact with threads, in which case it isn't a bug in linuxthreads. In any case, 
the JRE works correctly on the same system, so its something that needs to be fixed in libgcj.
Comment 3 Tom Tromey 2003-09-28 19:10:25 UTC
I recently discovered that if your program does not call
waitFor() on a process, it will remain as a zombie.
This is predictable, of course, since only waitFor() calls wait
to reap the child.  However, this is a difference from the
JDK, and thus arguably a bug.

I'm not too concerned about LinuxThreads problems; the world
is moving to NPTL...
Comment 4 Andrew Pinski 2003-11-08 01:29:31 UTC
*** Bug 12956 has been marked as a duplicate of this bug. ***
Comment 5 David Daney 2003-11-08 01:38:30 UTC
The way to solve the problem on non-NPTL linux systems is to create a thread
that is dedicated to forking and waiting for all execed processes.  This is the
approach that Sun's runtime uses.
Comment 6 Bryce McKinlay 2003-11-08 01:45:08 UTC
That sounds like the right approach. We could possibly simplify a lot of a lot of natPosixProcess.cc 
by doing this.

A related bug I noticed recently is that Process.destroy() leaves a zombie, because it also doesnt 
call waitpid().
Comment 7 Andrew Pinski 2004-03-24 06:39:24 UTC
*** Bug 14709 has been marked as a duplicate of this bug. ***
Comment 8 Bryce McKinlay 2004-07-09 20:21:39 UTC
Some more info in this thread:

http://gcc.gnu.org/ml/java-patches/2004-q3/msg00126.html
Comment 9 GCC Commits 2004-08-12 16:20:19 UTC
Subject: Bug 11801

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	daney@gcc.gnu.org	2004-08-12 16:20:12

Modified files:
	libjava        : Makefile.am Makefile.in configure configure.in 
	                 posix-threads.cc 
	libjava/gcj    : Makefile.in javaprims.h 
	libjava/include: Makefile.in config.h.in 
	libjava/java/lang: PosixProcess.java Runtime.java 
	                   natPosixProcess.cc 
	libjava/testsuite: Makefile.in 

Log message:
	2004-08-12  David Daney  <ddaney@avtrex.com>
	
	PR libgcj/11801
	* java/lang/PosixProcess.java: Rewrote.
	* java/lang/natPosixProcess.cc: Rewrote.
	* java/lang/Runtime.java (execInternal): Declare throws IOException.
	* gcj/javaprims.h (ConcreteProcess$ProcessManager): Declare.
	* posix-threads.cc (block_sigchld) New function.
	(_Jv_ThreadRegister) Use it.
	(_Jv_ThreadStart) Use it.
	* configure.in (PLATFORM_INNER_NAT_HDRS): New AC_SUBST() used in...
	* Makefile.am: ... to specify extra native headers.
	* configure: Regenerated.
	* include/config.h: Regenerated.
	* Makefile.in: Regenerated.
	* gcj/Makefile.in: Regenerated.
	* include/Makefile.in: Regenerated.
	* testsuite/Makefile.in: Regenerated.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/Makefile.am.diff?cvsroot=gcc&r1=1.398&r2=1.399
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/Makefile.in.diff?cvsroot=gcc&r1=1.424&r2=1.425
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/configure.diff?cvsroot=gcc&r1=1.225&r2=1.226
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/configure.in.diff?cvsroot=gcc&r1=1.203&r2=1.204
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/posix-threads.cc.diff?cvsroot=gcc&r1=1.34&r2=1.35
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/gcj/Makefile.in.diff?cvsroot=gcc&r1=1.50&r2=1.51
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/gcj/javaprims.h.diff?cvsroot=gcc&r1=1.51&r2=1.52
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/include/Makefile.in.diff?cvsroot=gcc&r1=1.51&r2=1.52
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/include/config.h.in.diff?cvsroot=gcc&r1=1.52&r2=1.53
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/lang/PosixProcess.java.diff?cvsroot=gcc&r1=1.5&r2=1.6
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/lang/Runtime.java.diff?cvsroot=gcc&r1=1.15&r2=1.16
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/lang/natPosixProcess.cc.diff?cvsroot=gcc&r1=1.18&r2=1.19
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/testsuite/Makefile.in.diff?cvsroot=gcc&r1=1.61&r2=1.62

Comment 10 David Daney 2004-08-12 16:28:40 UTC
Fixed by the patch.