Details
-
Bug
-
Status: Closed
-
Minor
-
Resolution: Won't Fix
-
3.0.4
-
None
-
None
-
Solaris 10, JDK 1.7.0
Description
See mailing list discussion for background. When a reactor build creates a plugin JAR and then loads classes from it, a JVM crash is a possibility:
[INFO] Installing /export/home/hudson/hudson-slave/workspace/sis-jdk7/sis-build-helper/target/sis-build-helper-0.3-jdk7-SNAPSHOT.jar to /export/home/hudson/hudson-slave/maven-repositories/0/org/apache/sis/sis-build-helper/0.3-jdk7-SNAPSHOT/sis-build-helper-0.3-jdk7-SNAPSHOT.jar ...moving on to another project in the reactor... [INFO] --- sis-build-helper:0.3-jdk7-SNAPSHOT:collect-jars (default) @ sis-utility --- # # A fatal error has been detected by the Java Runtime Environment:
This could happen for example if two people were running the same build concurrently; if one Maven process is trying to load classes from the JAR at the same time as another is rebuilding that JAR, there will be a problem. On Windows, one of the processes will simply fail with an I/O error due to mandatory file locks. On Unix, the OS will not stop the clash in this way, but there will be a worse issue: libzip.so will be trying to load a ZIP entry based on a stale copy of the ZIP index, so it loads bogus data, and (being not very robustly written) crashes, taking the whole JVM with it.
Since this class of problem is most likely to occur when loading classes from SNAPSHOT JARs in the local repository, I would suggest Maven simply not do this. Instead, use File.createTempFile to make a new /tmp/*.jar; use deleteOnExit to clean it up at process end (or if possible delete it sooner, e.g. upon conclusion of the reactor build, or at any time when it can be determined that mojo execution from this JAR must have ceased); copy the snapshot JAR from the local repo to this temp location; and load from there.
This means that problems will be limited to the much less likely event that someone is rebuilding the JAR during the very short period during which the file copy happens. And on Unix, the result might be a corrupted JAR file (and thus class loading errors which fail the build somehow), but not a mysterious JVM crash.
If this proposal sounds good, let me know and I can try to write a patch. (GitHub pull request would be easiest; I am an Apache committer.)
