[
https://issues.apache.org/jira/browse/MNG-5437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MNG-5437.
-------------------------------
Resolution: Won't Fix
I have experienced the very same issue with Java 8 and recent Maven 3.5.x on
FreeBSD in Maven Integration Testing Suite. One would actually need to rework
ITs for this.
Give that one can disable {{mmap}} via system property and Java 9 does not use
native code anymore for this. Closing as won't fix.
> Do not load plugins from snapshot JARs
> --------------------------------------
>
> Key: MNG-5437
> URL: https://issues.apache.org/jira/browse/MNG-5437
> Project: Maven
> Issue Type: Bug
> Components: Class Loading
> Affects Versions: 3.0.4
> Environment: Solaris 10, JDK 1.7.0
> Reporter: Jesse Glick
> Priority: Minor
>
> See [mailing list
> discussion|http://mail-archives.apache.org/mod_mbox/www-builds/201302.mbox/browser]
> for background. When a reactor build creates a plugin JAR and then loads
> classes from it, a JVM crash is a possibility:
> {code:none}
> [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:
> {code}
> 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.)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
