www-builds mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: Apache build infrastructure or Oracle JVM problem: crash in native JDK code
Date Wed, 06 Feb 2013 00:30:46 GMT
On 5 February 2013 17:59, Jesse Glick <typrase@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

Mime
View raw message