Java Errors at ZIP_GetEntry and newEntry


Applies To

Java SE JDK and JRE - Version 6 to 8
Oracle WebLogic Server - Version 12.2.1.4.0 to 12.2.1.4.0 [Release 12c]
Any platform.


Introduction

A crash in Java SE 8 is seen when reading zip files. The HotSpot Fatal Error Log (hs_err_pid_.log) shows crash signatures similar to the following::

# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0xffffffff7ea8241c, pid=<PID>, tid=<TID>
#
# JRE version: Java(TM) SE Runtime Environment (8.0_112-b15) (build 1.8.0_112-b15)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.112-b15 mixed mode solaris-sparc compressed oops)
# Problematic frame:
# C [libc.so.1+0x18241c] memcpy%sun4v-hwcap3+0x968
#
...
Stack: [0xffffffff12600000,0xffffffff12680000], sp=0xffffffff12678590, free space=481k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [libc.so.1+0x18241c] memcpy%sun4v-hwcap3+0x968
C [libzip.so+0x15eac] ZIP_GetEntry2+0x100
C [libzip.so+0x358c] Java_java_util_zip_ZipFile_getEntry+0x94
J 483 java.util.zip.ZipFile.getEntry(J[BZ)J (0 bytes) @ 0xffffffff6ac6abe4 [0xffffffff6ac6aaa0+0x144]
< ... cut ... >
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGBUS (0x7) at pc=0x00007f34165d4d10, pid=<PID>, tid=<TID>
#
# JRE version: Java(TM) SE Runtime Environment (8.0_201-b09) (build 1.8.0_201-b09)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.201-b09 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# C [libzip.so+0x11d10] newEntry.isra.4+0x60
..
Stack: [0x00007f33da3bd000,0x00007f33da4be000], sp=0x00007f33da4ba770, free space=1013k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [libzip.so+0x11d10] newEntry.isra.4+0x60
C [libzip.so+0x129fe] ZIP_GetEntry2+0xde
C [libzip.so+0x3a75] Java_java_util_zip_ZipFile_getEntry+0x85
J 218 java.util.zip.ZipFile.getEntry(J[BZ)J (0 bytes) @ 0x00007f3401324a0e [0x00007f3401324940+0xce]
< ... cut ... >

Cause

This is a known issue, caused by application code that fails to synchronize access to a jar file. Most crashes in ZIP_GetEntry occur when a jar file being accessed is modified or overwritten while the JVM instance is running. Because the HotSpot JVM maps each jar file’s central directory structure into memory using mmap, when a jar file is modified or overwritten on the disk, the JVM’s copy of the data becomes inconsistent with the jar file on the disk. Any subsequent attempt to read and load entries from the modified jar file can result in this type of crash.


Solutions

A few solution options:

  1. The most effective solution is to improve the application code to avoid modifying jar files while they are in use.

  2. Upgrade to Long Term Support (LTS) version JDK 11, JDK 17, or newer supported version.

An enhancement is included in Java SE 9 and later versions**1,2**, which uses a ZipFile implementation that does not store the jar file in memory, thereby avoiding the problem that causes most of these types of crashes.  See JDK-8145260 - To bring j.u.z.ZipFile’s native implementation to Java to remove the expensive jni cost and mmap crash risk.

  1. Alternatively, use the following workaround on Solaris, Linux or macOS systems:

Add the -Dsun.zip.disableMemoryMapping=true  system property to your ‘java’ command line arguments. 

This system property disables mmap usage by disabling mapping the JAR file central directory structure into memory, allowing you to avoid most crashes caused by buggy application code that erroneously modifies JAR files while they are in use. This option was introduced with Java SE 1.6 update 21 as noted in the release notes.

(1) It is Oracle policy that enhancements are not backported to previously released versions.  In line with that, there is no plan to backport this enhancement to Java SE 8 or older versions, as noted in JDK-8146693 - To bring j.u.z.ZipFile’s native implementation to Java to remove the expensive jni cost and mmap crash risk[2]. For Java SE 8 and older versions, the only JDK-provided solution is the workaround listed above.

**(2)**Java SE 9 was a non-LTS version that is no longer supported. See the Oracle Java SE Support Roadmap for the currently supported Oracle Java SE versions and their support timelines.


Last reviewed on Sat Feb 01 2025 00:00:00 GMT+0000 (Coordinated Universal Time)