[ 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)