Я получил сбой JVM на производственном сервере.Сгенерировал лог в /tmp/jvm-32627/hs_error.log.Начало файла:
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007f4cdd7fba55, pid=32627, tid=139964606174976
#
# JRE version: OpenJDK Runtime Environment (7.0_79-b14) (build 1.7.0_79-mockbuild_2015_07_24_09_26-b00)
# Java VM: OpenJDK 64-Bit Server VM (24.79-b02 mixed mode linux-amd64 compressed oops)
# Derivative: IcedTea 2.5.5
# Distribution: CentOS release 6.6 (Final), package rhel-2.5.5.4.el6-x86_64 u79-b14
# Problematic frame:
# V [libjvm.so+0x610a55]
#
# 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 include
# instructions on how to reproduce the bug and visit:
# http://icedtea.classpath.org/bugzilla
#
--------------- T H R E A D ---------------
Current thread (0x00007f4b1b90c000): JavaThread "Java2D Disposer" daemon [_thread_in_vm, id=33107, stack(0x00007f4c0c91d000,0x00007f4c0ca1e000)]
siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), si_addr=0x0000000000000000
Registers:
RAX=0x0000000000000000, RBX=0x00007f4b1b90c000, RCX=0x00007f4c0ca1c480, RDX=0x00007f4cddfe11a0
RSP=0x00007f4c0ca1c450, RBP=0x00007f4c0ca1c4e0, RSI=0x00007f4b1b90c000, RDI=0x00007f4c0ca1c480
R8 =0x00007f4c0ca1c490, R9 =0x0000000000000000, R10=0x00007f4cddfd7ef8, R11=0x0000000000000002
R12=0x00007f4b1b90c1d8, R13=0x00007f4b6c12d850, R14=0x00000000000000c2, R15=0x0000000000000000
RIP=0x00007f4cdd7fba55, EFLAGS=0x0000000000010246, CSGSFS=0x0000000000000033, ERR=0x0000000000000004
TRAPNO=0x000000000000000e
Top of Stack: (sp=0x00007f4c0ca1c450)
0x00007f4c0ca1c450: 00007f4b1b90c000 00007f4c001c3758
0x00007f4c0ca1c460: 00007f4c0ca1c470 00000000000000c2
0x00007f4c0ca1c470: 00007f4b1b90c000 00007f4c0ca1c480
0x00007f4c0ca1c480: 00007f4b1b90c000 0000000000000000
0x00007f4c0ca1c490: 0000000000000004 00007f4c001c37a8
0x00007f4c0ca1c4a0: 00007f4b1b90c000 523beb0a00000001
0x00007f4c0ca1c4b0: 00007f4b6c12d850 00007f4b1b90c1d8
0x00007f4c0ca1c4c0: 00007f4b6c0bc320 00007f4b6c12d850
0x00007f4c0ca1c4d0: 00007f4b6c054f40 00007f4b1b90c000
0x00007f4c0ca1c4e0: 00007f4c0ca1c500 00007f4c0c0cbe31
0x00007f4c0ca1c4f0: 00007f4b6c12d930 0000000000000001
0x00007f4c0ca1c500: 00007f4b6c12d6a0 000000358b610f17
0x00007f4c0ca1c510: 00007f4b6c04fc90 00007f4b6c12d6a0
0x00007f4c0ca1c520: 000000358b89b6e0 000000358b6119d4
0x00007f4c0ca1c530: 00007f4b6c12d6a0 00007f4b6c04fc90
(стек продолжается еще на 2000 строк или около того ...)
JVM - это компиляция IcedTea 2 (OpenJDK 1.7.0_79), выполнял Tomcat 7 и работает на CentOS 6.6 (ядро Linux 2.6.32-573.el6.x86_64).
После некоторых исследований кажется, что поток Java2D Disposer - это поток, используемый для освобождения нативногоресурсы, используемые Java2D и AWT и не управляемые GC.Я не могу понять, почему это происходит с помощью сервера JavaEE ...
У нас был этот сбой прошлой ночью, но исследования показали, что он, вероятно, произошел в первый раз в октябре 2017 года и во второй раз в марте 2018 года.сбой через 6 или 8 месяцев можно было бы считать приемлемым, но эта система критична для бизнеса (даже если в ней действительно много ошибок, плохой запах кода, старые версии библиотек и инструментов и т. д.), и мне бы очень хотелосьчтобы избавиться от проблемы.
Обычно у нас должен быть дамп ядра, но дамп ядра, конечно, отключен, поэтому у нас ничего нет.
Кто-нибудь знает, что происходит?и как это решить?