Bug ID: JDK-4784281 (process) Process code leaks processes (sol)

Type: Bug
Component: core-libs
Sub-Component: java.lang
Affected Version: 1.3.0,1.3.1,1.4.0,1.4.1

Priority: P3
Status: Closed
Resolution: Duplicate
OS: generic
CPU: generic

Submitted: 2002-11-25
Updated: 2006-03-17
Resolved: 2006-03-17

While investigating 4750978 I noticed a few problems with the Solaris process
code that will occur whenever a new working directory is specified to
Runtime.exec but the directory does not exist.

  - The current native code responds to this situation by throwing an exception
    in the child process.  This is pointless, since the exception will never be
    delivered, and it risks locking up the VM.

  - The child process never exits, so if this happens frequently the VM will
    chew up OS resources until a fork fails with ENOMEM.

  - The converted form of the directory pathname is never freed, so there's a
    small memory leak.

These problems appear to have been introduced way back in 1.3.0 when the
exec-with-dir feature was first implemented.

-- ###@###.### 2002/11/25

EVALUATION The changes for 4790606: (process) Native forkAndExec code should be unified (sol, lnx) caused the process leak to be fixed in 5.0. The process code is still not perfect, and error handling will be improved further with 4811767: (process) Runtime.exec should throw IOException when workdir does not exist (Unix) 4052517: (process) Solaris Runtime.exec won't execute programs belonging to other groups but strictly speaking, this one is fixed in 5.0, so... Closing as a dup of 4790606

17-03-2006

EVALUATION The submitter is correct. -- ###@###.### 2002/11/25 After a fork(), the rules change. Throwing an exception is useless, since the catcher is in a different process. What we have here is a failure to communicate. So we add a new way to communicate. In addition to the three standard file descriptors, we add another set of pipe file descriptors specifically to communicate failures in the exec itself. If there is a failure to exec, we send back some information over the pipe identifying the nature of the error. We invent a trivial protocol to identify the errors. There's only one tricky thing with the above design. What happens if the exec succeeds?? The parent process will be waiting for a success message on the pipe, but clearly if the exec succeeds, there is no way anymore to send a success message. The solution to this puzzle is to set the close-on-exec flag on the file descriptor. When exec() succeeds, the parent is notified via an EOF on the pipe. This change should be coordinated with the changes for 4790606 (process) Native forkAndExec code should be unified (sol, lnx) 4052517 (process) Solaris Runtime.exec won't execute programs belonging to other groups ###@###.### 2003-05-01

01-05-2003

Duplicate :	JDK-4790606 - (process) Native forkAndExec code should be unified (sol, lnx)
Relates :	JDK-4750978 - (process) Runtime.exec/Process.waitFor hang when a new directory is given (lnx)
Relates :	JDK-4052517 - (process) Runtime.exec won't execute programs belonging to other groups on Unix
Relates :	JDK-4811767 - (process) Runtime.exec should throw IOException when workdir does not exist (Unix)