On 5 February 2013 17:59, Jesse Glick <typr...@gmail.com> wrote: > 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. (**)
Sorry, but a pure Java application should not be able to cause a JVM crash. In this case, # SIGSEGV (0xb) at pc=0xfee952ce, pid=2229, tid=20 A pure Java app can of course cause exceptions. But the JVM should not crash when running pure Java - if it does, the JVM is faulty. However JNI apps can of course cause crashes such as SIGSEV. > 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
