Hello, Haven't seen this problem when I had one build process. Thus, we cannot take into account the case of one Maven process for sure. In my setup I increased the number of build executors. By default it is 2, I have 5. All jobs in my Jenkins are interconnected, they have Maven dependencies specified what is not uncommon. I believe it is something to do with Jenkins. It gives possibility to have multiple build processes at the same time on the same machine. And it fails to perform that.
Br, Alexander. On 7 September 2012 18:40, Jesse Glick <jgl...@cloudbees.com> wrote: > 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. >
