www-builds mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse Glick <typr...@gmail.com>
Subject Re: Apache build infrastructure or Oracle JVM problem: crash in native JDK code
Date Tue, 05 Feb 2013 17:59:56 GMT
On 02/04/2013 09:23 AM, Martin Desruisseaux wrote:
> the crash occurs in the C/C++ implementation of java.util.zip.ZipFile.getEntry(String)

This is almost always a symptom of user error rather than a JDK bug; or at least any bug report
to Oracle along these lines will be rejected. Something in your build is 
trying to modify a JAR file which is still held open by some other Java code, and the JRE’s
libzip.so (*) is not written to handle changes “beneath its feet”—it just 
crashes rather than reporting an error to the code calling getEntry. (**)

You need to be careful to close any JAR files before they are potentially overwritten; JarFile.close
in a finally-block is the usual idiom, or for indirect usage from 
URLClassLoader you must call its close method (added in Java 7).

 From the stack trace, it seems the caller is the Jenkins Maven runner (for native Maven jobs).
The JAR it is loading would be that of a mojo. So my suspicion would be 
that your build is somehow running a mojo from some JAR in the workspace (or local repository)
which has been modified between the time the JAR was opened and the time 
the crash occurs (the end of the mojo).

Specifically your console [1] suggests that sis-utility is running a just-built (SNAPSHOT)
version of sis-build-helper:collect-jars, which could be dangerous especially 
if there are concurrent builds using the same workspace. Consider publishing release versions
of mojo projects rather than running snapshots, i.e. version them 
independently of the main code.

(*) On Windows the problem cannot arise because of mandatory file locks: the attempt to change
the JAR would fail with an IOException.

(**) I have advocated that libzip be used only for the bootstrap class loader, with a pure
Java (perhaps NIO-based) implementation of ZipFile for user code, which would 
improve robustness and diagnosis if not actually correct the error. Last I checked the JRE
team declined to put in this engineering effort, though a proposal made through 
OpenJDK might succeed if someone wanted to do the work.

[1] https://builds.apache.org/job/sis-jdk7/lastFailedBuild/console

View raw message