Сбой JVM в java.util.zip.ZipFile.getEntry

Следующий файл журнала привел к сбою JVM.

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

В первый раз это произошло согласно некоторым онлайн материалам, на которые я ссылаюсь, я поставил параметр JVM -Dsun.zip.disableMemoryMapping=true. Но все равно происходит такой же сбой JVM. В разных местах сообщается о многих подобных проблемах, но ни один из ответов не дал надежного решения этой проблемы.

Я уже прошел следующий пост. Но я не вижу никакого возможного решения.

Сбой JVM при memcpy во время загрузки класса

Любая помощь высоко ценится.


person Ruchira Gayan Ranaweera    schedule 12.07.2016    source источник
comment
Вы пытались включить дамп ядра?   -  person while true    schedule 12.07.2016
comment
@ пока правда да. включение дампа ядра не решает эту проблему. Это позволит создать дамп ядра (аварийный дамп), который содержит информацию для дальнейшего изучения. Это просто снимок памяти.   -  person Ruchira Gayan Ranaweera    schedule 12.07.2016
comment
Если проблема в том, что файл управляется другим процессом, когда вы пытаетесь его прочитать, вы можете сделать временную копию zip-файла и прочитать из копии.   -  person Andreas    schedule 21.07.2016
comment
ни один из ответов не дал надежного решения. Решение состоит в том, чтобы не изменять файлы JAR приложения во время работы приложения.   -  person apangin    schedule 08.10.2016
comment
@apangin да. Но это не в нашей власти. В этом проблема. Все происходит на уровне JVM. Вы копали больше об этом? если вы это сделаете, вы увидите, как эта проблема происходит, почему? Я также знаю, что вы упомянуты.   -  person Ruchira Gayan Ranaweera    schedule 09.10.2016
comment
@RuchiraGayanRanaweera Содержимое некоторого файла JAR изменяется во время доступа к файлу. Конечно, это нарушает структуру ZIP, например. смещения в заголовке файла становятся недействительными. Это не JVM, который изменяет файлы JAR. Это делается где-то снаружи. Таким образом, JVM ничего не может с этим поделать. Это должно быть исправлено в способе развертывания/обслуживания приложения или в самом приложении, если по какой-либо причине происходит перезапись файлов JAR.   -  person apangin    schedule 09.10.2016


Ответы (2)


Проблема заключается в том, что файл zip/JAR перезаписывается во время использования. Использование -Dsun.zip.disableMemoryMapping=true решит проблему. Вы используете JDK7 update 51, доступны сборки раннего доступа JDK9, в которых есть решение для этой проблемы.

Проверьте исходную проблему https://bugs.openjdk.java.net/browse/JDK-8142508 исправлено в 9 сборке раннего доступа 97.

person Fairoz    schedule 13.07.2016
comment
Спасибо за помощь. Согласно моему сообщению -Dsun.zip.disableMemoryMapping=true проблема не решается. - person Ruchira Gayan Ranaweera; 13.07.2016
comment
Недавно у меня была такая же проблема. Сбой был вызван перезаписью файлов JAR, которые использовались. - person Corey; 15.07.2016
comment
Вы имеете в виду перенаписано? Перезаписать и переопределить — это разные слова с разными значениями в контексте ИТ. (И на простом английском тоже...) - person Stephen C; 20.07.2016
comment
Вы пробовали это -Dsun.zip.disableMemoryMapping=true? - person Fairoz; 04.08.2017
comment
@ObiWan-PallavJha Я не решил проблему. Вместо этого я избегаю этого, завершая программу Java перед копированием новых файлов jar поверх старых. Когда новые файлы jar будут скопированы, я перезапущу программу Java. - person Corey; 08.08.2017

Мы также сталкиваемся с такой же проблемой. Эта проблема касается определенного набора файлов, а не всех. Это вызывается из нативных методов java. Таким образом, мы не можем решить проблему из кода. Изменение конфигурации также не решило проблему. Итак, решение этой проблемы (по крайней мере, в моем случае),

  1. Создать поток отключения
  2. Всякий раз, когда jvm выходит из строя, перезапускайте тот же jvm
  3. Пропустите эту ошибку, вызывающую zip-файл, и перейдите к следующему файлу.
person Vijayakumar    schedule 13.10.2016