JDK-6713913 : Fatal errors during jar file processing
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util.jar
  • Affected Version: javadb_10.0
  • Priority: P1
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic
  • CPU: generic
  • Submitted: 2008-06-12
  • Updated: 2011-02-21
  • Resolved: 2008-08-07
Related Reports
Duplicate :  
Relates :  
Relates :  
Relates :  
GlassFish build uses Maven (maven.apache.org) and like Ant the whole build happens in a single JVM. During build, we try to create, read, write many jar files. Randomly we see failures like "invalid block type" from the jar layer in JDK. It happens on all kinds of Unix platforms, can;t tell about Windows as I have not seen on Windows. It happens when we invoke maven (maven.apache.org) which is written in Java and is responsible for all the jar file processing. I am hoping that JDK team has sufficient serviceability tool to observe what's going on inside the process.

Here is how you can reproduce it: 
1. svn co https://svn.dev.java.net/svn/glassfish-svn/trunk/v3/javaee-api
Use your java.net id to login if need be.
2. cd javaee-api
3. JAVA_HOME=<Path to JDK 1.5> mvn install
Use mvn version 2.0.7.

Step #3 is where it all happens. First time, it will take a long time as maven has to download all the dependencies, but subsequent runs will be pretty fast. It bombs like this:

[INFO] [jar:jar]
[INFO] Building jar: /space/ss141213/WS/gf/v3.trunk.new/javaee-api/javax.javaee/target/javax.javaee-10.0-SNAPSHOT.jar
[INFO] [bundle:bundle {execution: osgi-bundle}]
[INFO] ------------------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] jzentry == 0,
jzfile = 137952112,
total = 8,
name = /space/ss141213/WS/gf/v3.trunk.new/javaee-api/javax.transaction/target/javax.transaction-10.0-SNAPSHOT.jar,
i = 2,
message = invalid LOC header (bad signature)
[INFO] ------------------------------------------------------------------------
[INFO] Trace
java.lang.InternalError: jzentry == 0,
jzfile = 137952112,
total = 8,
name = /space/ss141213/WS/gf/v3.trunk.new/javaee-api/javax.transaction/target/javax.transaction-10.0-SNAPSHOT.jar,
i = 2,
message = invalid LOC header (bad signature)
       at java.util.zip.ZipFile$3.nextElement(ZipFile.java:429)
       at java.util.zip.ZipFile$3.nextElement(ZipFile.java:415)
       at aQute.lib.osgi.ZipResource.build(ZipResource.java:41)
       at aQute.lib.osgi.ZipResource.build(ZipResource.java:32)
       at aQute.lib.osgi.Jar.<init>(Jar.java:35)
       at org.apache.felix.bundleplugin.BundlePlugin.getClasspath(BundlePlugin.java:676)
       at org.apache.felix.bundleplugin.BundlePlugin.execute(BundlePlugin.java:227)
       at org.apache.felix.bundleplugin.BundlePlugin.execute(BundlePlugin.java:218)
       at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443)
       at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
       at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480)
       at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459)
       at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
       at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
       at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
       at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
       at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
       at org.apache.maven.cli.MavenCli.main(MavenCli.java:280)
       at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
       at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
       at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
       at java.lang.reflect.Method.invoke(Method.java:585)
       at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
       at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
       at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
       at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1 minute 7 seconds
[INFO] Finished at: Fri May 30 10:19:08 PDT 2008
[INFO] Final Memory: 20M/37M
[INFO] ---------------------------------------------------------------------
More information from submitter (sent to me via email):

It fails with several kinds of messages. The particular incidence reported in the bug report reports the message as : /invalid LOC header (bad signature)./ I have also seen messages like: /Embedded error: invalid distance code/, /invalid block type/, etc. If you follow the instructions to reproduce the bug, I am sure you can see all these messages when you run the command repeatedly. More over, on every occasion, it fails with different jar files. In every occasion, I have been able to open the offending jar file very successfully.

EVALUATION The specific problem encountered in building GlassFish has been resolved by way of change in the maven bundle plugin; for discussion see: https://issues.apache.org/jira/browse/FELIX-661 The underlying issue, of overwriting the contents of a ZIP file, remains; see 4425695 and its related bugs.

EVALUATION The root cause of the problem is that a ZipFile instance zf1 is created, then the ZIP file in the filesystem is changed, and then a second ZipFile instance zf2 is created. The two ZipFile instances both reference the same native data structures (in zip_util.c), but those are out-of-date when zf2 is created. Instance zf1 should have been closed first. This is discussed further in 4425695 and its See Also bugs. The problem can be examined by suitable use of truss and with some debug output added in zip_util.c and perhaps also ZipFile.{c,java}

EVALUATION See comments.

EVALUATION I am attaching a zip file which can be used to reproduce the issue. Just unzip in your javaee-api directory and run 'mvn clean install'

EVALUATION I have just used the instructions to do "mvn install" 7 times with no failures (on solaris amd64; builds were across NFS-mounted filesystem). This does not constitute a small reproducible test case, which is required in order for me keep this bug open. Please provide such a test case or we really have no choice except to mark it as not reproducible.

EVALUATION I am attaching the jar file. There is nothing bad with this jar. Yes, it is one of the many jars that gets generated during the build process. My java version is: java version "1.5.0_13-rev" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_13-rev-b07) Java HotSpot(TM) Client VM (build 1.5.0_13-rev-b07, mixed mode, sharing) I don't think it matters if you use the latest UR. I hope JDK team investigates it soon.

EVALUATION The message "invalid block type" comes from zlib-1.1.3/infblock.c. Could you please attach a stack trace showing that message? And provide a JAR file which demonstrates the problem? The message in the given trace, "invalid LOC header (bad signature)", comes from zip_util.c.