On 09/07/2012 08:15 AM, Alexander Potapov wrote:
SIGBUS (0x7) at pc=0x00007ffae80661b0, pid=26833, tid=140715262596864
J java.util.zip.ZipFile.getEntry(JLjava/lang/String;Z)J
J java.util.zip.ZipFile.getEntry(Ljava/lang/String;)Ljava/util/zip/ZipEntry;
j
org.eclipse.jdt.internal.compiler.classfmt.ClassFileReader.read(Ljava/util/zip/ZipFile;Ljava/lang/String;Z)Lorg/eclipse/jdt/internal/compiler/classfmt/ClassFileReader;+2
This Java code (in JDT) is trying to read classes from a JAR file which has been, or is being, overwritten (probably by the same Maven process) with a newer version since
the JAR was opened. Oracle-derived JVMs use libzip.so/dll (rather than pure Java code) to implement ZipFile, and this library was not designed to handle ZIP files being
replaced “under its feet”. I have repeatedly advocated that ZipFile use a more robust pure Java implementation (leaving libzip for use only by HotSpot loading the
bootclasspath, which is expected to be immutable), but no one in the Java team seems to consider this a priority, so do not expect it to be fixed unless someone pushes it
from OpenJDK. In the meantime the workarounds, insofar as you can control the code immediately involved in the bug, are:
1. Prevent the JAR from being overwritten.
2. Rather than reading the JAR “in-place”, make a temporary copy
(File.createTempFile/deleteOnExit) and open that instead.
Note that this bug does not occur on Windows—mandatory file locking means that if the ZipFile is open for reading, any attempt to overwrite (or delete) it will fail with
an IOException or the like.
