2016-07-12 43 views
8

Il seguente file di registro ha provocato un arresto anomalo di JVM.JVM si è arrestato in modo anomalo in java.util.zip.ZipFile.getEntry

# 
# 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; 

Alla prima volta che questo si è verificato, come per alcune online materiali mi riferisco, ho messo l'opzione JVM -Dsun.zip.disableMemoryMapping=true. Ma sta succedendo lo stesso crash JVM. Ci sono molti problemi segnalati simili a questo in vari luoghi ma nessuna delle risposte ha fornito una soluzione risoluta per questo problema.

Ho già seguito il post seguente. Ma non c'è una soluzione possibile che io possa vedere.

JVM crash while memcpy during class load

Qualsiasi aiuto è molto apprezzato.

+0

hai provato a abilitare il dumping principale? –

+0

@whiletrue si. consentire il dumping di base non risolve questo problema. Abiliterà il core dump (crash dump) che contiene informazioni per indagare di più. È solo un'istantanea della memoria. –

+0

Se il problema è che il file viene manipolato da un altro processo mentre si tenta di leggerlo, è possibile creare una copia temporanea del file zip e leggerla dalla copia. – Andreas

risposta

9

Il problema è zip/il file JAR viene sovrascritto mentre è in uso. L'utilizzo di -Dsun.zip.disableMemoryMapping=true risolverà il problema, si sta utilizzando JDK7 update 51, sono disponibili build di accesso anticipato JDK9 che hanno la soluzione per questo.

Verificare il problema originale https://bugs.openjdk.java.net/browse/JDK-8142508 che è stato fissato in 9 Early Access accumulo 97.

+0

Grazie per l'aiuto. Come da mio post '-Dsun.zip.disableMemoryMapping = true' non risolve il problema. –

+0

Ho avuto lo stesso problema di recente. Il crash è stato causato dalla sovrascrittura dei file JAR che erano in uso. – Corey

+2

Intendi ** scritto **? Sovrascrivi e sostituisci sono parole diverse con significati diversi nel contesto IT. (E anche in inglese semplice ...) –

0

Siamo anche di fronte lo stesso tipo di problema. Questo problema riguarda un insieme specifico di file e non per tutti. Provoca dai metodi nativi di java. Quindi non possiamo gestire il problema dal codice. Anche la modifica della configurazione non ha risolto il problema. Quindi la soluzione per questo problema (almeno nel mio caso),

  1. Creare filo shutdownhook
  2. Ogni volta che va in crash JVM riavviare la stessa JVM
  3. Vai tale errore causando file zip e procedere con il file successivo.
Problemi correlati