www-builds mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse Glick <typr...@gmail.com>
Subject Re: Apache build infrastructure or Oracle JVM problem: crash in native JDK code
Date Wed, 06 Feb 2013 18:39:18 GMT
On 02/06/2013 06:12 AM, Martin Desruisseaux wrote:
> the approach that we wanted to apply has been used for more than 5 years on Windows,
Solaris, Linux Gentoo, Linux Ubuntu, MacOS, and other Hudson/Jenkins servers without any JVM

Perhaps you were just lucky, or perhaps there is something in the current Jenkins configuration
that makes the crash more likely—for example, if the job were marked as 
permitting multiple concurrent builds.

I will reiterate that while upgrading the Java 7 build is a good idea, it will probably not
affect this bug.

> if the JVM were "allowed" to crash when clobbering an open ZIP file, then any user or
external application touching a ZIP file could crash a running JVM...

Yes, that is exactly what happens. The problem does not affect typical Java applications since
ZIP files are normally just used for class loading and a normal application 
has a static code base that would not be overwritten while it is running; but it is a scourge
of developer tools such as build systems and IDEs, as well as applications 
with module systems that permit dynamic reload.

To Ted Dunning’s request for the bug number—searching on bugs.sun.com seems to be broken,
and as I no longer work for Oracle I cannot use the internal search tool. 
Fortunately I managed to dig it up using other means: it is #4425695 [1].

Passing -Dsun.zip.disableMemoryMapping=true to the JVM accessing the ZIP file (the Maven process
in this case) may avoid the hard crash, as in NetBeans bug #190481 [2], 
though the ZIP would probably still be unreadable so you would just get other class loading

While I would still recommend that the SIS project not run a SNAPSHOT plugin (e.g. from the
reactor), it may be possible for Maven core to avoid the crash (and almost 
always avoid corruption & Windows lock errors too): rather than creating a class realm
from ~/.m2/repository/**/*-SNAPSHOT.jar directly, which is inherently unsafe in a 
multiuser operating system, copy that JAR to /tmp (hoping no one tries to overwrite it during
this brief interval), mark deleteOnExit, and open that temp file for the 
class loader instead. If there are any Maven committers listening who want to go with this
idea (olamy?), great, otherwise I could file a JIRA ticket for it and maybe try 
a patch.

[1] http://bugs.sun.com/view_bug.do?bug_id=4425695
[2] http://netbeans.org/bugzilla/show_bug.cgi?id=190481

View raw message