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 crash
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 errors.
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
