JVM crash in java.util.zip.ZipFile.getEntry

Solution Verified - Updated

Environment

  • Red Hat build of OpenJDK 6/7/8
  • Oracle JDK 6/7/8

Issue

  • JVM crash in java.util.zip.ZipFile.getEntry with SIGBUS or SIGSEGV SEGV_MAPERR.

  • For example, a fatal error log hs_err_pid<PID>.log shows:

      #
  # A fatal error has been detected by the Java Runtime Environment:
  #
  #  SIGBUS (0x7) at pc=0x00002aaaab034021, pid=6244, tid=1227151680
  #
  # JRE version: 6.0_17-b04
  # Java VM: Java HotSpot(TM) 64-Bit Server VM (14.3-b01 mixed mode linux-amd64 )
  # Problematic frame:
  # C  [libzip.so+0xb021]
  #
  
  ...(snip)...
  
  
  siginfo:si_signo=SIGBUS: si_errno=0, si_code=2 (BUS_ADRERR), si_addr=0x00002aab3a5d73bb
  
  ...(snip)...
          
  Stack: [0x000000004914d000,0x000000004924e000],  sp=0x0000000049249270,  free space=1008k
  Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
  C  [libzip.so+0xb021]
          
  Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
  J  java.util.zip.ZipFile.getEntry(JLjava/lang/String;Z)J
  J  sun.misc.URLClassPath$JarLoader.getResource(Ljava/lang/String;Z)Lsun/misc/Resource;
  J  java.net.URLClassLoader$2.run()Ljava/lang/Object;
  v  ~StubRoutines::call_stub
  ...(snip)...

  • JBoss sometimes crashes, during hot deploy of a large application.

  • SIGSEGV in fatal error log:

# Problematic frame:
# C  [libc.so.6+0x14d667]  __memcpy_ssse3+0xb57
...

Stack: [0x00007fa1bf03b000,0x00007fa1bf13c000],  sp=0x00007fa1bf138608,  free space=1013k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [libc.so.6+0x14d667]  __memcpy_ssse3+0xb57
C  [libzip.so+0x6034]  ZIP_GetEntry2+0xf4
C  [libzip.so+0x3c1d]  Java_java_util_zip_ZipFile_getEntry+0xfd
J 302  java.util.zip.ZipFile.getEntry(J[BZ)J (0 bytes) @ 0x00007fa287303dce [0x00007fa287303d00+0xce]
J 473 C2 java.util.jar.JarFile.getEntry(Ljava/lang/String;)Ljava/util/zip/ZipEntry; (22 bytes) @ 0x00007fa2873a5e94 [0x00007fa2873a5b40+0x354]
...

Resolution

  • Avoid overwriting the zip or jar file that is in use.

  • Set system property -Dsun.zip.disableMemoryMapping which has been available since OpenJDK 7, OpenJDK 1.6.0.38 and Content from www.oracle.com is not included.Oracle JDK 6 u23. Please refer to Content from www.oracle.com is not included.Java for Business 6 Release Notes for details. In case, here is the excerpt from the release note:

    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.Zipfile implementation (on Solaris and Linux platforms). Solaris or Linux applications that use java.util.zip.ZipFile may 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 (at the cost of some loss in performance). 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.

However, there is a more fundamental application bug that should be addressed, as attempting to modify a file while it is in use is not a reliable/valid use case.

The OpenJDK developers have determined this is too risky to fix in OpenJDK8. It is best to address the primary application issue or disable memory mapping for ZipFile (at the cost of some loss in performance).

Root Cause

Diagnostic Steps

  • Ask for Java fatal error log named hs_err_pid<pid>.log (where <pid> is the java process ID) which will be generated under the process current directory at the JVM crash. It can be confirmed from the user.dir environment variable in the boot.log (or server.log) for JBoss (typically $JBOSS_HOME/bin/).
  • Test with ZipFile memory mapping disabled and verify the issue goes away:
-Dsun.zip.disableMemoryMapping=true
  • Review the application code and/or processes to determine why there is an attempt to modify a file while Java has it open.
SBR
Product(s)
Components
Category
Tags

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.