JDK-4977607 : Compilation error java.lang.InternalError: jzentry == 0
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Affected Version:
    8.0pe,8.1ee,1.4.2,1.4.2_08,5.0,5.0u2,5.0u6,6 8.0pe,8.1ee,1.4.2,1.4.2_08,5.0,5.0u2,5.0u6,6
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS:
    linux,windows_nt,windows_2000,windows_xp linux,windows_nt,windows_2000,windows_xp
  • CPU: x86
  • Submitted: 2004-01-13
  • Updated: 2016-03-23
  • Resolved: 2006-07-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.
6 b91Fixed
Related Reports
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Relates :  
Name: gm110360			Date: 01/13/2004

java version "1.4.2_02"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_02-b03)
Java HotSpot(TM) Client VM (build 1.4.2_02-b03, mixed mode)

Microsoft Windows XP [version 5.1.2600]

Information: 1 error
Information: 0 warnings
Information: An exception has occurred in the compiler (1.4.2_02). Please file a bug at the Java Developer Connection (http://java.sun.com/cgi-bin/bugreport.cgi)  after checking the Bug Parade for duplicates. Include your program and the following diagnostic in your report.  Thank you.
Information: java.lang.InternalError: jzentry == 0,
Information:  jzfile = 9973032,
Information:  total = 69,
Information:  name = D:\java\j2ee\jdk\jre\lib\jce.jar,
Information:  i = 2,
Information:  message = invalid LOC header (bad signature)
Information: 	at java.util.zip.ZipFile$2.nextElement(ZipFile.java:321)
Information: 	at com.sun.tools.javac.v8.code.ClassReader.openArchive(ClassReader.java:975)
Information: 	at com.sun.tools.javac.v8.code.ClassReader.list(ClassReader.java:1218)
Information: 	at com.sun.tools.javac.v8.code.ClassReader.listAll(ClassReader.java:1339)
Information: 	at com.sun.tools.javac.v8.code.ClassReader.fillIn(ClassReader.java:1357)
Information: 	at com.sun.tools.javac.v8.code.ClassReader.complete(ClassReader.java:1052)
Information: 	at com.sun.tools.javac.v8.code.Symbol.complete(Symbol.java:372)
Information: 	at com.sun.tools.javac.v8.comp.Enter.visitTopLevel(Enter.java:467)
Information: 	at com.sun.tools.javac.v8.tree.Tree$TopLevel.accept(Tree.java:390)
Information: 	at com.sun.tools.javac.v8.comp.Enter.classEnter(Enter.java:442)
Information: 	at com.sun.tools.javac.v8.comp.Enter.classEnter(Enter.java:456)
Information: 	at com.sun.tools.javac.v8.comp.Enter.complete(Enter.java:596)
Information: 	at com.sun.tools.javac.v8.comp.Enter.main(Enter.java:582)
Information: 	at com.sun.tools.javac.v8.JavaCompiler.compile(JavaCompiler.java:331)
Information: 	at com.sun.tools.javac.v8.Main.compile(Main.java:569)
Information: 	at com.sun.tools.javac.Main.compile(Main.java:36)
Information: 	at com.sun.tools.javac.Main.main(Main.java:27)
Information: 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
Information: 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
Information: 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
Information: 	at java.lang.reflect.Method.invoke(Method.java:324)
Information: 	at com.intellij.rt.compiler.JavacRunner.main(JavacRunner.java:49)
Error:  line (0) The compiler did not terminate normally. Exit code is 4

This bug can be reproduced always.
(Incident Review ID: 231734) 

EVALUATION See bug 4615343 for a description of the changes made to the zip file implementation.

EVALUATION No regression test included as I'm not able to reproduce the problem. I tried modifying a jar so that one of its entries was too large but I just get: java.util.zip.ZipException: unexpected EOF at java.util.zip.ZipInputStream.read(ZipInputStream.java:166) at sun.tools.jar.Main.extractFile(Main.java:819) at sun.tools.jar.Main.extract(Main.java:754) at sun.tools.jar.Main.run(Main.java:210) at sun.tools.jar.Main.main(Main.java:1014)

SUGGESTED FIX Index: j2se/src/share/classes/com/sun/tools/javac/util/DefaultFileManager.java --- /tmp/geta20772 2006-06-13 22:26:29.000000000 -0700 +++ DefaultFileManager.java 2006-06-13 22:26:15.000000000 -0700 @@ -399,11 +399,18 @@ public class ZipArchive implements Archive { protected final Map<String,List<String>> map; protected final ZipFile zdir; - public ZipArchive(ZipFile zdir) { + public ZipArchive(ZipFile zdir) throws IOException { this.zdir = zdir; this.map = new HashMap<String,List<String>>(); - for (Enumeration<? extends ZipEntry> e = zdir.entries(); e.hasMoreElements(); ) - addZipEntry(e.nextElement()); + for (Enumeration<? extends ZipEntry> e = zdir.entries(); e.hasMoreElements(); ) { + ZipEntry entry; + try { + entry = e.nextElement(); + } catch (InternalError ex) { + throw new IOException(ex); + } + addZipEntry(entry); + } } void addZipEntry(ZipEntry entry) { @@ -450,7 +457,7 @@ public class SymbolArchive extends ZipArchive { final File origFile; - public SymbolArchive(File orig, ZipFile zdir) { + public SymbolArchive(File orig, ZipFile zdir) throws IOException { super(zdir); this.origFile = orig; }

EVALUATION As part of the work for JSR 199 (javax.tools), this problem will be diagnosed better.

WORK AROUND The most likely cause of this problem is a corrupt jar file. However, it is also possible that the compiler runs out of memory. So if you suspect you're running out of memory, try increasing the system memory or compiling a smaller set of files. When reducing the set of files to compile, the -sourcepath compiler option can be useful.

EVALUATION Summary: If there are errors getting the entry, the return value is always 0. An error in this case could be out of memory, or a corrupt jar file. Detail: ZipFile.entries().nextEntry() // ZipFile.java Java_java_utilzip_ZipFile_getNextEntry() // ZipFile.c ZIP_getNextEntry() // zip_util.c newEntry() // zip_util.c The result of newEntry() is what ultimately determines the value of jzentry that is reported in the stack traces. zip_util.c is compiled with -DUSE_MMAP. As best I can tell, the return value will be NULL only if malloc returns NULL. So perhaps they're compiling on machines with limited memory. Doubtful. But if the jar file has an entry that is corrupt in its name, "extra data" or comment, such that an unreasonably-large malloc is attempted, that could fail, and the result would be jzentry = 0 as we've seen.

EVALUATION The compiler must catch such errors and diagnose the problem: a corrupt jar file.

EVALUATION This bug report lacks a reproducible test case. The most likely cause of this problem is a corrupted jce.jar file. ###@###.### 2004-01-13