11

Following log file resulting a JVM crash. 

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007f60ddce2058, pid=117268, tid=140052313204480
#
# JRE version: Java(TM) SE Runtime Environment (7.0_51-b13) (build 1.7.0_51-b13)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (24.51-b03 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# C  [libzip.so+0x5058]  ZIP_GetEntry+0x78
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.sun.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

---------------  T H R E A D  ---------------

Current thread (0x00007f5f4c01a800):  JavaThread "EJB default - 3" [_thread_in_native, id=117526, stack(0x00007f607850e000,0x00007f607860f000)]

siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), si_addr=0x0000000000000278

Registers:
RAX=0x0000000000000000, RBX=0x00007f607860c3c0, RCX=0x0000003a4d2182a0, RDX=0x000000000000009e
RSP=0x00007f607860c370, RBP=0x00007f607860c3a0, RSI=0x00007f5fdc0060a1, RDI=0x0000000000000010
R8 =0x00000000000001e5, R9 =0x2e786176616a2f73, R10=0x6e6172742e6c6d78, R11=0x0000000741902898
R12=0x00007f5fdc006340, R13=0x00007f5f4c01a9e8, R14=0x0000000066c00f1d, R15=0x00007f607860c3c0
RIP=0x00007f60ddce2058, EFLAGS=0x0000000000010246, CSGSFS=0x0000000000000033, ERR=0x0000000000000004
  TRAPNO=0x000000000000000e

Top of Stack: (sp=0x00007f607860c370)
0x00007f607860c370:   000000387860c3a0 00007f607860c3c0
0x00007f607860c380:   0000000000000038 00007f5f4c01a9e8
0x00007f607860c390:   00007f607860c3c0 00007f607860c818
0x00007f607860c3a0:   00007f607860c800 00007f60ddce0eed
0x00007f607860c3b0:   01007f5f4c01b6d0 00007f5fdc006340
0x00007f607860c3c0:   464e492d4154454d 656369767265732f
0x00007f607860c3d0:   2e786176616a2f73 6e6172742e6c6d78
0x00007f607860c3e0:   72542e6d726f6673 656d726f66736e61
0x00007f607860c3f0:   79726f7463614672 00007f6078600000
0x00007f607860c400:   00007f5f4c01a9e8 0000000000000000
0x00007f607860c410:   00007f607860cc90 00007f60d5006233
0x00007f607860c420:   00007f60d5005310 00007f6000000000
0x00007f607860c430:   00007f607860cce0 00007f607860cc90
0x00007f607860c440:   00007f5f4c01a800 00007f5f4c00d970
0x00007f607860c450:   00007f5f4c01b690 00007f5f4c01b6e0
0x00007f607860c460:   00007f5f4c01ba78 00000000000003d8
0x00007f607860c470:   00007f607860da90 00000005402d81a0
0x00007f607860c480:   00007f60d256f5c0 00007f5f4c01b6d8
0x00007f607860c490:   00007f607860cc90 00007f5f4c01a800
0x00007f607860c4a0:   00007f5f4c01b6d0 00007f5f4c01b6d8
0x00007f607860c4b0:   00007f607860cc90 00007f5f4c01a800
0x00007f607860c4c0:   00007f5fa8003ac0 00007f5fa8003ac0
0x00007f607860c4d0:   00007f607860cd20 00007f60decc9d8d
0x00007f607860c4e0:   00007f607860c500 00007f607860cd30
0x00007f607860c4f0:   00007f5f4c01a9e8 0000000000000000
0x00007f607860c500:   00007f607860cd80 00007f60d5006233
0x00007f607860c510:   00007f60d5005310 00007f6000000000
0x00007f607860c520:   00007f607860cdd8 00007f607860cd80
0x00007f607860c530:   00007f5f4c01a800 00007f5f4c01a800
0x00007f607860c540:   00007f5fa8003ac0 00007f5fa8003ac0
0x00007f607860c550:   00007f5f4c01b6c8 00007f60decc9d8d
0x00007f607860c560:   00007f607860c580 0000000000000410 

Instructions: (pc=0x00007f60ddce2058)
0x00007f60ddce2038:   45 85 c0 0f 84 ff 00 00 00 44 89 f0 31 d2 41 f7
0x00007f60ddce2048:   b4 24 88 00 00 00 49 8b 84 24 80 00 00 00 89 d2
0x00007f60ddce2058:   8b 1c 90 0f 1f 44 00 00 4d 8b ac 24 98 00 00 00
0x00007f60ddce2068:   4d 85 ed 74 1e 49 8b 7d 00 4c 89 fe e8 cf d7 ff 

Register to memory mapping:

RAX=0x0000000000000000 is an unknown value
RBX=0x00007f607860c3c0 is pointing into the stack for thread: 0x00007f5f4c01a800
RCX=0x0000003a4d2182a0: <offset 0x2182a0> in /lib64/libpthread.so.0 at 0x0000003a4d000000
RDX=0x000000000000009e is an unknown value
RSP=0x00007f607860c370 is pointing into the stack for thread: 0x00007f5f4c01a800
RBP=0x00007f607860c3a0 is pointing into the stack for thread: 0x00007f5f4c01a800
RSI=0x00007f5fdc0060a1 is an unknown value
RDI=0x0000000000000010 is an unknown value
R8 =0x00000000000001e5 is an unknown value
R9 =0x2e786176616a2f73 is an unknown value
R10=0x6e6172742e6c6d78 is an unknown value
R11=0x0000000741902898 is an unknown value
R12=0x00007f5fdc006340 is an unknown value
R13=0x00007f5f4c01a9e8 is an unknown value
R14=0x0000000066c00f1d is an unknown value
R15=0x00007f607860c3c0 is pointing into the stack for thread: 0x00007f5f4c01a800


Stack: [0x00007f607850e000,0x00007f607860f000],  sp=0x00007f607860c370,  free space=1016k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [libzip.so+0x5058]  ZIP_GetEntry+0x78
C  [libzip.so+0x3eed]  Java_java_util_zip_ZipFile_getEntry+0xad
J  java.util.zip.ZipFile.getEntry(J[BZ)J

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
J  java.util.zip.ZipFile.getEntry(J[BZ)J
J  java.util.jar.JarFile.getEntry(Ljava/lang/String;)Ljava/util/zip/ZipEntry;
J  org.jboss.modules.JarFileResourceLoader.getResource(Ljava/lang/String;)Lorg/jboss/modules/Resource;
J  org.jboss.modules.ModuleClassLoader.loadResourceLocal(Ljava/lang/String;)Ljava/util/List;
J  org.jboss.modules.Module.getResourceAsStream(Ljava/lang/String;)Ljava/io/InputStream;

At the first time this occured as per some online materials I refer,I put the JVM option -Dsun.zip.disableMemoryMapping=true. But still same JVM crash is happening. There are many reported issues similar to this in various places but none of the answers provided a firm solution for this issue.

I already went through the following post. But there is no possible solution I can see.

JVM crash while memcpy during class load

Any help is highly appreciated.

Community
  • 1
  • 1
Ruchira Gayan Ranaweera
  • 34,993
  • 17
  • 75
  • 115
  • did you try to enable core dumping? – while true Jul 12 '16 at 10:27
  • @whiletrue yes. enabling core dumping is not solving this issue. It will enable the core dump(crash dump) which contains info to investigate more. It is just a memory snapshot. – Ruchira Gayan Ranaweera Jul 12 '16 at 10:30
  • If the problem is, that the file is manipulated from another process while you try to read it you could make a temporary copy of the zip file and read from the copy. – Andreas Jul 21 '16 at 11:55
  • *"none of the answers provided a firm solution"* - The solution is not to modify application JAR files while the application is running. – apangin Oct 07 '16 at 22:46
  • @apangin yes. But this is not in our control. That's the issue. All happen in JVM level. Did you dig it more on this? if you do so you will see how is this issue happening any why? I am also aware the fact you are mentioned. – Ruchira Gayan Ranaweera Oct 09 '16 at 03:43
  • @RuchiraGayanRanaweera The contents of some JAR file is changed while the file is being accessed. Of course, this breaks ZIP structure, e.g. offsets in the file header become invalid. This is not JVM that modifies JAR files. This is done somewhere externally. So, JVM can do nothing about it. This should be fixed in the way you deploy/maintain the application, or in the application itself if it happens to overwrite JAR files for any reason. – apangin Oct 09 '16 at 11:07

2 Answers2

12

Issue is zip/JAR file is being overwritten while in use. Using -Dsun.zip.disableMemoryMapping=true will solve the problem, You are using JDK7 update 51, JDK9 early access builds are available that has solution for this.

Check the original issue https://bugs.openjdk.java.net/browse/JDK-8142508 that has been fixed in 9 early access build 97.

Fairoz
  • 1,616
  • 13
  • 16
  • Thanks for the help. As per my post `-Dsun.zip.disableMemoryMapping=true` not fix the issue. – Ruchira Gayan Ranaweera Jul 13 '16 at 11:41
  • I had the same problem recently. The crash was caused by overwriting JAR files that were in use. – Corey Jul 15 '16 at 19:39
  • 2
    Do you mean over**written**? Overwrite and override are different words with different meanings in the IT context. (And in plain English too ...) – Stephen C Jul 20 '16 at 12:01
  • have you tried this "-Dsun.zip.disableMemoryMapping=true"? – Fairoz Aug 04 '17 at 06:07
  • @ObiWan-PallavJha I didn't solve the problem. Instead I avoid it by terminating the Java program before copying new jar files over the old ones. When the new jar files have been copied, I restart the Java program. – Corey Aug 08 '17 at 19:04
0

We are also facing same kind of issue. This issue is for specific set of files and not for all. It is causing from native methods of java. So we cannot handle the issue from the code. Changing the configuration also not solved the problem. So the solution for this problem(At least in my case),

  1. Create shutdownhook thread
  2. Whenever jvm crashes restart the same jvm
  3. Skip that error causing zip file and proceed with the next file.
Vijayakumar
  • 303
  • 4
  • 10