JDK-5077725 : 1.5 jvm exports global symbols from libz that should be kept private
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util.jar
  • Affected Version: 5.0
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_10
  • CPU: sparc
  • Submitted: 2004-07-23
  • Updated: 2004-07-28
  • Resolved: 2004-07-28
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.
Other
5.0 b60Fixed
Related Reports
Relates :  
Description
The 1.5 jvm (build 1.5.0-beta-b32) uses the zlib compression library for
processing manifests. The symbols within the jvms private version of 
libz have a global scope and are therefore available as interfaces for
other modules within the jvms address space (i.e JNI code) to bind to
at link time.

This causes a problem for JNI libraries that have a dependency on libz.
In our case, any DTrace consumer library will link in libctf.so.1 which
in turn has a dependency on libz.so.1. Ordinarily this will be resolved
against the libz.so.1 provided with Solaris in /usr/lib but, in this
case, any binding is done against the versions that are private to the
jvm.

At the moment this breaks 64 bit JNI applications as the private libz
that the jvm uses is compiled differently (uLong == 4 bytes instead of 8
on LP64 data model) to the libz.so.1 that is shipped with Solaris. All
DTrace consumers have to be 64 bit.

The scope of the jvms internal compression routines should be modified
so that they are not available to link against when modules are loaded
into the jvm.

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: generic FIXED IN: tiger-rc INTEGRATED IN: tiger-b60 tiger-rc
08-09-2004

EVALUATION ###@###.### 2004-07-26 This problem was introduced in Solaris by the multiple JRE work. As part of this the launcher itself has a private set of a few zip routines (This in itself is an exoediancy to be removed). These symbols are the ones clashing with Dtrace on Solaris. The fix is to use a ld mapfile to scope these symbols (and most others while we are at it) to be local to the launcher.
08-09-2004

SUGGESTED FIX Use a mapfile to alter the scope of the libz symbols exported by the jvm from global to local. A suitable mapfile would be: #cat mapfile { local; adler32; inflate; inflateEnd; inflateInit2_; inflateInit_; inflateReset; inflateSetDictionary; inflateSync; inflateSyncPoint; zError; zlibVersion; }; ###@###.### 2004-07-26 Actually, the mapfile to be used is: { global: main; # Provides basic adb symbol offsets environ; # Required by Java run time _environ; __environ_lock; local: *; }; The suggested mapfile could be expanded (there are levels of calls here), but its better to just make everything possible local. Note that several utilities in Solaris (ON) do this as just a matter of cleanliness.
08-09-2004