Hello once again, Should I report bug about that?
Br, Alexander On 10 September 2012 12:02, Alexander Potapov <outro...@gmail.com> wrote: > 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. >> > >
