- JDK-7129299 : JVM crash issue related to jar files
This may be another cases where a zip/JAR file is overwritten while it is being used. In JDK7 the property
sun.zip.disableMemoryMappingcan be used to disable the mmapping of the central directory to avoid this when there is stepping on toes.
- Java SE 6 Advanced and Java SE 6 Support (formerly known as Java SE for Business 6) Release Notes
Changes in 6u21-rev-b09
Disabling mmap Usage (on Solaris or Linux)
This release includes a new system property,
sun.zip.disableMemoryMapping, which allows the user to disable the mmap usage in Sun’s
java.util.zip.Zipfileimplementation (on Solaris and Linux platforms). Solaris or Linux applications that use
java.util.zip.ZipFilemay experience a SIGBUS VM crash if the application accidentally overwrites any zip or jar files that are still being used by the same Java runtime.
Although this is a programming error of the offending application, this system property provides a solution to avoid the VM crash. With the property set to true (
-Dsun.zip.disableMemoryMapping=true, or simply
-Dsun.zip.disableMemoryMapping) the Sun JDK/JRE runtime disables the mmap usage and the VM crash that might otherwise occur by overwriting the jar or zip file can be avoided.
- [Bug 190481] New: Consider using -Dsun.zip.disableMemoryMapping=true
See Java bugs #4425695, #6929479. As of JDK 6u21 or 7, a system property can be set to prevent JVM crashes when overwriting an open JAR. (Only applies to Unix, since on Windows you could not open the JAR for writing to begin with.) This may be helpful to avoid crashes caused by buggy Ant scripts, etc. But needs to be checked to see if performance degrades as a result.
- JVM crashes due to corrupted JAR file
The reason why JAR files cannot be modified underneath the JVM is because the JVM caches each JAR file’s central directory structure (using mmap) for performance reasons. The central directory is the part of the JAR file that describes its contents – i.e. entry locations, sizes and so on. Caching it in memory means that the JVM does not have to read it from the disk every time an entry in that JAR file needs to be accessed.
If the JAR file is modified after this region has been cached, then the JVM’s version of the central directory will no longer be an accurate description of the JAR file as it exists on disk and the end result is a SIGBUS or SIGSEGV when the JVM attempts to load an entry from the modified JAR file (usually during class loading).
Note: This has been a well known limitation of the HotSpot JVM for a long time but Oracle did recently introduce an option to work around the issue. From 1.6.0_23 onwards, the following option can be added to the command line to completely disable memory mapping for ZIP/JAR files:
Enabling this option will impact performance because the VM will have to conduct some additional disk IO every time it reads an entry from a JAR file (to interrogate the central directory structure).
As a result, you should verify whether any jar files were modified some time prior to the crashes starting, while the JVM was still running.
- weblogic jvm -Dsun.zip.disableMemoryMapping=true
There are three possible scenarios here:
1. While a class is in use it is dynamically reloaded from a jar file.
2. While a jar file is being accessed by the class loader, the jar file is being modified.
3. A Jarfile which was bigger than 4GB was accessed (applies to Java 6 and earlier only).