I got a JVM crash on a production server. It generated a log in /tmp/jvm-32627/hs_error.log. The beginning of the file is:
# 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
(The stack goes on for 2000 more lines or so...)
The JVM is a IcedTea 2 compilation (OpenJDK 1.7.0_79), was executing a Tomcat 7 and is running on a CentOS 6.6 (Linux 2.6.32-573.el6.x86_64 kernel).
After some research, it seems the Java2D Disposer thread is a thread used to free native resources used by Java2D and AWT and which are not managed by the GC. I can't see why it is sollicitated by a JavaEE server...
We had that crash last night, but investigations showed it probably happened a first time in October 2017 and a second time in March 2018. One crash in 6 or 8 months could be considered acceptable, but that system is business critical (even if really flawed by so many bugs, bad smelling code, old versions of libraries and tools, and so on...) and I really would like to get rid of the problem.
Normally, we should have a core-dump, but core-dump has been of course disabled, so we have nothing.
Does anyone know what is happening and how to solve it?
