JDK-6354700 : LD_LIBRARY_PATH polluted in children
  • Type: Enhancement
  • Component: tools
  • Sub-Component: launcher
  • Affected Version: 5.0
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: linux
  • CPU: x86
  • Submitted: 2005-11-23
  • Updated: 2011-01-27
  • Resolved: 2009-12-01
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7
7Resolved
Related Reports
Duplicate :  
Description
A DESCRIPTION OF THE REQUEST :
The Linux JRE adds three components to the LD_LIBRARY_PATH presumably to enable the loader to find the JRE's shared library files.  After it has served its purpose, this change to the environment remains and is inherited by any child processes which the user's Java causes to be executed.

JUSTIFICATION :
This sequence of commands, executed in an environment polluted by the JRE:

strace -o /tmp/trc date
grep jdk /tmp/trc | wc -l

Produced this output for me:

100

Whereas this sequence of commands:

unset LD_LIBRARY_PATH
strace -o /tmp/trc date
grep jdk /tmp/trc | wc -l

Produced this output for me:

0

Every shared library opened by every process searches this path.  date was just a simple example.  This takes time and provides no benefit.


EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
I think the JRE should remove elements it added to the LD_LIBRARY_PATH before passing that environment variable on to children which aren't part of its implementation.

ACTUAL -
This sequence of commands:

cat > LdLibraryPathPollutionTester.java <<EOF
<paste the supplied source code>
EOF
unset LD_LIBRARY_PATH
export LD_LIBRARY_PATH
javac LdLibraryPathPollutionTester.java
java LdLibraryPathPollutionTester

Produces this output for me:

/usr/local/jdk1.5.0_01/jre/lib/i386/client:/usr/local/jdk1.5.0_01/jre/lib/i386:/usr/local/jdk1.5.0_01/jre/../lib/i386

Showing that the JRE is polluting the environment of any children with three extra components on the LD_LIBRARY_PATH.


---------- BEGIN SOURCE ----------
import java.io.*;
import java.util.regex.*;

public class LdLibraryPathPollutionTester {
  public static void main(String[] arguments) {
    try {
      final Process process = Runtime.getRuntime().exec("env");
      LineNumberReader input = new LineNumberReader(new InputStreamReader(process.getInputStream()));
      Pattern pattern = Pattern.compile("^LD_LIBRARY_PATH=(.*)$");
      String line;
      while ((line = input.readLine()) != null) {
        Matcher matcher = pattern.matcher(line);
        if (matcher.matches()) {
          System.out.println(matcher.group(1));
        }
      }
    } catch (IOException exception) {
      exception.printStackTrace();
    }
  }
  
  private LdLibraryPathPollutionTester () {
  }
}

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

CUSTOMER SUBMITTED WORKAROUND :
The LD_LIBRARY_PATH can be restored to its previous value by the child process, if it has some way of knowing what the previous value was in its ancestor which called the JRE.  The workaround needs to be duplicated in every child.  If the Java in question is a generic program launcher of some kind, like a terminal emulator, this is unfortunately repetitive.

Comments
EVALUATION This problem is fixed via 6367077, closing this as duplicate.
01-12-2009

EVALUATION The submitter is correct; as an artifact of the current implementation the incoming LD_LIBRARY_PATH variable is modified before the jvm is started to include three directories in the jdk/jre. The best fix for this problem is not using LD_LIBRARY_PATH to resolve jdk-internal dependencies, bug 4769088.
28-11-2005