Re: Apache build infrastructure or Oracle JVM problem: crash in native JDK code
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
Re: ubuntu4 hung up?
Thanks. It helped. On Mon, Feb 4, 2013 at 11:58 PM, Niklas Gustavsson wrote: > On Tue, Feb 5, 2013 at 2:32 AM, Ted Dunning wrote: > > There are three builds running on ubuntu4. Two have been running for > over > > 30 hours. One has been running for nearly 8 hours. > > Killed and cleaned up. > > /niklas >
Re: Apache build infrastructure or Oracle JVM problem: crash in native JDK code
On 5 February 2013 17:59, Jesse Glick 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
Re: Apache build infrastructure or Oracle JVM problem: crash in native JDK code
On 02/05/2013 07:30 PM, sebb wrote: a pure Java application should not be able to cause a JVM crash Depends entirely on what you mean by “pure Java application”. When you have filesystem and Process access, you can do whatever the user shell account can do, which certainly includes triggering native errors. At any rate I personally agree that using java.util.zip in this way should not cause JVM crashes—but it does, and the JDK team has explicitly decided that this is “not a bug” and closed discussion. The workaround, or depending on your perspective the fix, is to ensure that you do not clobber an open ZIP file (which would also prevent a lock error on Windows).
Re: Apache build infrastructure or Oracle JVM problem: crash in native JDK code
On 6 February 2013 01:49, Jesse Glick wrote: > On 02/05/2013 07:30 PM, sebb wrote: >> >> a pure Java application should not be able to cause a JVM crash > > > Depends entirely on what you mean by “pure Java application”. When you have > filesystem and Process access, you can do whatever the user shell account > can do, which certainly includes triggering native errors. > At any rate I personally agree that using java.util.zip in this way should > not cause JVM crashes—but it does, and the JDK team has explicitly decided > that this is “not a bug” and closed discussion. Astonishing decision. I hope people complain until they relent. Seems very unwise to allow that behaviour - it undermines trust in the JVM. > The workaround, or depending > on your perspective the fix, is to ensure that you do not clobber an open > ZIP file (which would also prevent a lock error on Windows). I trust there aren't more such shortcuts in the JVM.
Re: Apache build infrastructure or Oracle JVM problem: crash in native JDK code
Do you have a reference to the bug? This is still a very early version of java 7. It would be good to update it. On Tue, Feb 5, 2013 at 5:49 PM, Jesse Glick wrote: > On 02/05/2013 07:30 PM, sebb wrote: > >> a pure Java application should not be able to cause a JVM crash >> > > Depends entirely on what you mean by “pure Java application”. When you > have filesystem and Process access, you can do whatever the user shell > account can do, which certainly includes triggering native errors. > > At any rate I personally agree that using java.util.zip in this way should > not cause JVM crashes—but it does, and the JDK team has explicitly decided > that this is “not a bug” and closed discussion. The workaround, or > depending on your perspective the fix, is to ensure that you do not clobber > an open ZIP file (which would also prevent a lock error on Windows). >
