JDK-6312057 : 64 bit jvm is not looking at LD_LIBRARY_PATH_64 to find the JNI libraries
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 7
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: linux
  • CPU: x86
  • Submitted: 2005-08-17
  • Updated: 2012-10-08
  • Resolved: 2005-09-22
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 6
6 b53Fixed
Related Reports
Relates :  
JDK-6254947 - java.library.path includes 32-bit usr/lib on 64-bit jvm
Relates :  
JDK-4731671 - launcher sets runpath incorrectly on Solaris
Description
jdk 5 is incorrectly looking at LD_LIBRARY_PATH (even for 64 bit) to load the libraries from java -> native side. Instead it should be looking at LD_LIBRARY_PATH_64 first before looking at LD_LIBRARY_PATH. This issue is blocking web server release.


web server 7 has a setup like 

native side => loads the JVM => initialized JVM looks at the configuration for class path and then loads the classes. This setup works fine for 32 bit web server.

For 64 bit web server, we use LD_LIBRARY_PATH_64 to point to the 64 bit libraries. We want JVM to also look only at LD_LIBRARY_PATH_64 to look for the libraries. But looks like some where in the jvm like (java.lang.ClassLoader.loadLibrary) is looking only at LD_LIBRARY_PATH to look for the libraries for both 32 bit as well as for 64 bit. 

If web server just sets LD_LIBRARY_PATH to point to 32 bit libraries and LD_LIBRARY_PATH_64 to point to 64 bit libraries, we get the following error:
Sun Java System Web Server 7.0 B08/16/2005 19:42
warning: CORE3283: stderr: java.lang.UnsatisfiedLinkError: /export/home/sn123202/ws7.ms7/iplanet/ias/server/work/B1/SunOS5.8_DBG.OBJ/lib/libj2eeplugin.so: ld.so.1: webservd: fatal: /export/home/sn123202/ws7.ms7/iplanet/ias/server/work/B1/SunOS5.8_DBG.OBJ/lib/libj2eeplugin.so: wrong ELF class: ELFCLASS32
warning: CORE3283: stderr:      at java.lang.ClassLoader$NativeLibrary.load(Native Method)
warning: CORE3283: stderr:      at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1751)
warning: CORE3283: stderr:      at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1676)
warning: CORE3283: stderr:      at java.lang.Runtime.loadLibrary0(Runtime.java:822)
warning: CORE3283: stderr:      at java.lang.System.loadLibrary(System.java:992)
warning: CORE3283: stderr:      at com.sun.enterprise.web.connector.nsapi.logging.NSAPIServerHandler.<clinit>(NSAPIServerHandler.java:29)
warning: CORE3283: stderr:      at com.iplanet.ias.server.logging.ServerLogManager$1.run(ServerLogManager.java:175)
warning: CORE3283: stderr:      at java.security.AccessController.doPrivileged(Native Method)
warning: CORE3283: stderr:      at com.iplanet.ias.server.logging.ServerLogManager.initializeServerLogger(ServerLogManager.java:166)
warning: CORE3283: stderr:      at com.iplanet.ias.server.logging.ServerLogManager.initializeLogger(ServerLogManager.java:253)
warning: CORE3283: stderr:      at com.iplanet.ias.server.logging.BaseLogManager.doInitialize
Logger(BaseLogManager.java:99)
warning: CORE3283: stderr:      at com.iplanet.ias.server.logging.BaseLogManager.addLogger(Ba
seLogManager.java:148)
warning: CORE3283: stderr:      at java.util.logging.Logger.getLogger(Logger.java:232)
warning: CORE3283: stderr:      at org.apache.commons.logging.impl.Jdk14Logger.<init>(Jdk14Lo
gger.java:96)
warning: CORE3283: stderr:      at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Nat
ive Method)
warning: CORE3283: stderr:      at sun.reflect.NativeConstructorAccessorImpl.newInstance(Nati
veConstructorAccessorImpl.java:39)
warning: CORE3283: stderr:      at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(
DelegatingConstructorAccessorImpl.java:27)
warning: CORE3283: stderr:      at java.lang.reflect.Constructor.newInstance(Constructor.java
:494)
warning: CORE3283: stderr:      at org.apache.commons.logging.impl.LogFactoryImpl.newInstance
(LogFactoryImpl.java:548)
warning: CORE3283: stderr:      at org.apache.commons.logging.impl.LogFactoryImpl.getInstance
(LogFactoryImpl.java:289)
warning: CORE3283: stderr:      at org.apache.commons.logging.impl.LogFactoryImpl.getInstance
(LogFactoryImpl.java:259)
warning: CORE3283: stderr:      at org.apache.commons.logging.LogFactory.getLog(LogFactory.ja
va:390)
warning: CORE3283: stderr:      at org.apache.catalina.util.StringManager.<clinit>(StringMana
ger.java:57)
warning: CORE3283: stderr:      at com.iplanet.ias.server.J2EERunner.<clinit>(J2EERunner.java
:61)
warning: CORE3283: stderr: java.lang.NoClassDefFoundError
warning: CORE3283: stderr:      at com.iplanet.ias.server.logging.ServerLogManager$1.run(Serv
erLogManager.java:175)
warning: CORE3283: stderr:      at java.security.AccessController.doPrivileged(Native Method)
warning: CORE3283: stderr:      at com.iplanet.ias.server.logging.ServerLogManager.initialize
ServerLogger(ServerLogManager.java:166)
warning: CORE3283: stderr:      at com.iplanet.ias.server.logging.ServerLogManager.initialize
Logger(ServerLogManager.java:253)
warning: CORE3283: stderr:      at com.iplanet.ias.server.logging.BaseLogManager.doInitialize
Logger(BaseLogManager.java:99)
warning: CORE3283: stderr:      at com.iplanet.ias.server.logging.BaseLogManager.addLogger(Ba
seLogManager.java:148)
warning: CORE3283: stderr:      at java.util.logging.Logger.getLogger(Logger.java:232)
warning: CORE3283: stderr:      at org.apache.commons.logging.impl.Jdk14Logger.<init>(Jdk14Lo
gger.java:96)
warning: CORE3283: stderr:      at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Nat
ive Method)
warning: CORE3283: stderr:      at sun.reflect.NativeConstructorAccessorImpl.newInstance(Nati
veConstructorAccessorImpl.java:39)
warning: CORE3283: stderr:      at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(
DelegatingConstructorAccessorImpl.java:27)
warning: CORE3283: stderr:      at java.lang.reflect.Constructor.newInstance(Constructor.java
:494)warning: CORE3283: stderr:      at org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:548)
warning: CORE3283: stderr:      at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:289)
warning: CORE3283: stderr:      at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:259)
warning: CORE3283: stderr:      at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:390)
warning: CORE3283: stderr:      at org.apache.catalina.util.StringManager.<clinit>(StringManager.java:57)
warning: CORE3283: stderr:      at com.iplanet.ias.server.J2EERunner.<clinit>(J2EERunner.java:61)
failure: CORE4013: Internal error: Unable to create Java object: com/iplanet/ias/server/J2EERunner
failure: CORE4007: Internal error: Unexpected Java exception thrown (java.lang.UnsatisfiedLinkError: getServerRoot, getServerRoot), stack: java.lang.UnsatisfiedLinkError: getServerRoot
        at com.sun.enterprise.web.connector.nsapi.NSAPIRunner.getServerRoot(Native Method)
        at com.iplanet.ias.server.J2EERunner.<init>(J2EERunner.java:31)

failure: CORE2253: Error running Init function load-modules: initialization of libj2eeplugin.so failed

If web server 7 (64 bit) internally sets LD_LIBRARY_PATH=$LD_LIBRARY_PATH_64 at the time of starting the server, jvm is able to find the classes and right libraries perfectly fine. This is not acceptable for ws7 64 bit release. 

Really appreciate if some one can look into this and fix it as soon as possible.
Comments
EVALUATION The following public summary may be used as a release note: Solaris Hotspot VM java.library.path change: In previous releases, if the java.library.path property was not explicitly set, a Solaris Hotspot VM created by JNI_CreateJavaVM would in some cases incorrectly initialize the property. This behavior has been corrected in this release. The specific changes are as follows: * Initialize java.library.path from the data model specific LD_LIBRARY_PATH_32 or LD_LIBRARY_PATH_64 if it's set, otherwise LD_LIBRARY_PATH. * System crle(1) settings will be recognized. * The 64-bit VM will now correctly append /usr/lib/64 to java.library.path instead of /usr/lib. Except for the /usr/lib/64 change, these changes will only affect VMs created with JNI_CreateJavaVM. Applications created via the Java launcher will not be affected. In very rare cases, applications that used incorrect LD_LIBRARY_PATH settings to work around this bug may need to adjust their environment to avoid UnsatisfiedLinkErrors loading native libraries. In this case, it is recommended to correct your LD_LIBRARY_PATH setting or to explicitly set java.library.path to the desired value.
16-11-2005
EVALUATION Fixed by calling dlinfo() to determine the proper library path setting. See comments for further details.
12-09-2005