Jesse Glick created MNG-5437:
--------------------------------
Summary: Do not load plugins from snapshot JARs
Key: MNG-5437
URL: https://jira.codehaus.org/browse/MNG-5437
Project: Maven 2 & 3
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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
