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.<init>(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.bate...@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.<init>(Inflater.java:101)
> at java.util.zip.ZipFile.getInflater(ZipFile.java:448)
>
> It's because:
> - jdk changed structure size of z_stream 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.
>
>
