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

Reply via email to