Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-4784281

(process) Process code leaks processes (sol)

    Details

    • Type: Bug
    • Status: Closed
    • Priority: P3
    • Resolution: Duplicate
    • Affects Version/s: 1.3.0, 1.3.1, 1.4.0, 1.4.1
    • Fix Version/s: None
    • Component/s: core-libs
    • Labels:
      None
    • Subcomponent:
    • Introduced In Version:
    • CPU:
      generic
    • OS:
      generic

      Description

      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

        Issue Links

          Activity

          Hide
          martin Martin Buchholz added a comment -
          BT2: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
          Show
          martin Martin Buchholz added a comment - BT2: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
          Hide
          martin Martin Buchholz added a comment -
          BT2: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
          Show
          martin Martin Buchholz added a comment - BT2: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

            People

            • Assignee:
              martin Martin Buchholz
              Reporter:
              mr Mark Reinhold
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Imported:
                Indexed: