Do not let internal JDK zlib symbols leak out of fastdebug libzip.so (original) (raw)

Martin Buchholz martinrb at google.com
Sat Feb 23 18:06:35 UTC 2013


I am actually encountering this in openjdk7 with the old build system. I can repro the problem in openjdk8 with the old build system, but not the new one.

I don't know if you consider this a bug with the new build system - it's supposed to generate the same bits, after all???!! I'm not sure why - I'd guess something to do with VARIANT or FILES_m

It's highly dubious whether we should have this extremely subtle and error-prone distinction between release and fastdebug builds at all. Consider fixing this more fundamentally in Mapfile-vers.gmk, or at least document clearly why mapfiles are only on in OPT, and what the consequences might be.

ifeq ($(PLATFORM), linux)

ifeq ($(VARIANT), OPT)

OPT build MUST have a mapfile?

ifndef FILES_m FILES_m = mapfile-vers endif endif # VARIANT

Here's a repro recipe on Ubuntu Linux, running javac on any old source file:

env LD_PRELOAD="/usr/lib/x86_64-linux-gnu/libz.so" ~/ws/openjdk8/build/linux-amd64-fastdebug/j2sdk-image/bin/javac Main.java An exception has occurred in the compiler (1.8.0-internal). Please file a bug at the Java Developer Connection (http://java.sun.com/webapps/bugreport) after checking the Bug Parade for duplicates. Include your program and the following diagnostic in your report. Thank you. java.lang.InternalError at java.util.zip.Inflater.init(Native Method) at java.util.zip.Inflater.(Inflater.java:103) at java.util.zip.ZipFile.getInflater(ZipFile.java:448) at java.util.zip.ZipFile.getInputStream(ZipFile.java:367) at java.util.jar.JarFile.getBytes(JarFile.java:379) at java.util.jar.JarFile.getManifestFromReference(JarFile.java:178) at java.util.jar.JarFile.getManifest(JarFile.java:165) at com.sun.tools.javac.file.FSInfo.getJarClassPath(FSInfo.java:69) at com.sun.tools.javac.file.CacheFSInfo.getJarClassPath(CacheFSInfo.java:94) at com.sun.tools.javac.file.Locations$Path.addJarClassPath(Locations.java:304) at com.sun.tools.javac.file.Locations$Path.addFile(Locations.java:295) at com.sun.tools.javac.file.Locations$Path.addDirectory(Locations.java:217) at com.sun.tools.javac.file.Locations$Path.addDirectories(Locations.java:192) at com.sun.tools.javac.file.Locations$BootClassPathLocationHandler.computePath(Locations.java:630) at com.sun.tools.javac.file.Locations$BootClassPathLocationHandler.lazy(Locations.java:642) at com.sun.tools.javac.file.Locations$BootClassPathLocationHandler.getLocation(Locations.java:576) at com.sun.tools.javac.file.Locations.getLocation(Locations.java:677) at com.sun.tools.javac.file.JavacFileManager.getLocation(JavacFileManager.java:803) at com.sun.tools.javac.file.JavacFileManager.list(JavacFileManager.java:617) at com.sun.tools.javac.jvm.ClassReader.fillIn(ClassReader.java:2699) at com.sun.tools.javac.jvm.ClassReader.complete(ClassReader.java:2395) at com.sun.tools.javac.code.Symbol.complete(Symbol.java:434) at com.sun.tools.javac.comp.Enter.visitTopLevel(Enter.java:302) at com.sun.tools.javac.tree.JCTree$JCCompilationUnit.accept(JCTree.java:519) at com.sun.tools.javac.comp.Enter.classEnter(Enter.java:262) at com.sun.tools.javac.comp.Enter.classEnter(Enter.java:276) at com.sun.tools.javac.comp.Enter.complete(Enter.java:488) at com.sun.tools.javac.comp.Enter.main(Enter.java:473) at com.sun.tools.javac.main.JavaCompiler.enterTrees(JavaCompiler.java:990) at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:865) at com.sun.tools.javac.main.Main.compile(Main.java:517) at com.sun.tools.javac.main.Main.compile(Main.java:376) at com.sun.tools.javac.main.Main.compile(Main.java:365) at com.sun.tools.javac.main.Main.compile(Main.java:356) at com.sun.tools.javac.Main.compile(Main.java:76) at com.sun.tools.javac.Main.main(Main.java:61)

On Sat, Feb 23, 2013 at 3:51 AM, Alan Bateman <Alan.Bateman at oracle.com>wrote:

On 22/02/2013 22:03, Martin Buchholz wrote:

Hi Alan, Xueming, build-ers, I'd like you to do a code review. I've finally figured out why fastdebug jdk occasionally gives InternalError in the zip code. Exception in thread "main" java.lang.InternalError at java.util.zip.Inflater.init(Native Method) at java.util.zip.Inflater.(Inflater.java:101) at java.util.zip.ZipFile.getInflater(ZipFile.java:448) It's because: - jdk changed structure size of zstream struct - making jdk zlib incompatible with stock zlib - as a result of which, it is imperative to keep jdk zlib sequestered from system zlib - so need to not export zlib symbols from libzip.so - so need to tell makefiles to use linker script unconditionally http://cr.openjdk.java.net/~martin/webrevs/openjdk8/hide-zlib/ I see Sherman has created a bug for this but it turns out that someone else running with fastdebug ran into issues too: 8006319: fastdebug libzip.so is linked with global symbols, allowing symbols to be overridden I see you are proposing to update make/java/zip/Makefile so that is the old build. Looking at makefiles/CompileNativeLibraries.gmk (new build) then it looks to me that it is using the map file. I haven't checking the symbols in a fast debug build to double check so I'm curious if you've seen this with a recent (new) build. -Alan.



More information about the build-dev mailing list