Stack: [0xb0c00000,0xb0c80000], sp=0xb0c7c890, free space=498k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [libc_psr.so.1+0x700] memcpy+0x2f8
C [libzip.so+0xd19c]
C [libzip.so+0x2380] ZIP_GetEntry+0xe4
C [libzip.so+0x2800] Java_java_util_zip_ZipFile_getEntry+0xc4
j java.util.zip.ZipFile.getEntry(JLjava/lang/String;Z)J+0
j java.util.zip.ZipFile.getEntry(JLjava/lang/String;Z)J+0
j java.util.zip.ZipFile.getEntry(Ljava/lang/String;)Ljava/util/zip/ZipEntry;+31
j java.util.jar.JarFile.getEntry(Ljava/lang/String;)Ljava/util/zip/ZipEntry;+2
j java.util.jar.JarFile.getJarEntry(Ljava/lang/String;)Ljava/util/jar/JarEntry;+2
Most of the times, the crashes in ZIP_GetEntry occur when the jar file being accessed has been modified/overwritten while the JVM instance was running. For performance reasons, HotSpot JVM memory maps each Jar file's central directory structure using mmap. This is done so as to avoid reading the central directory structure data from the disk every time it needs to read entries from the Jar file. When a Jar file is modified or overwritten on the disk, the JVM's copy of the data read earlier becomes inconsistent with the jar file on the disk, and any attempt to read and load entries from the modified jar can result in an application crash.
Since 1.6.0_23, a property can be used to disable the memory mapping of the central directory structure of the Jar files:
-Dsun.zip.disableMemoryMapping=truePlease note that enabling this property would have some performance impact on the application as the JVM needs to read the central directory structure from the Jar files on the disk again and again whenever it reads a Jar file entry. So, it is best to ensure that the jar files are not modified or overwritten while the JVM has an image of them loaded.