ConcurrentGCThread 中 Java VM 的随机崩溃答案

【问题标题】：Random crashes of Java VM in ConcurrentGCThreadConcurrentGCThread 中 Java VM 的随机崩溃
【发布时间】：2009-05-13 22:08:26
【问题描述】：

在负载变化的情况下运行互联网应用程序的 JVM 存在问题。这个问题来来去去。有一天，我们看到三台虚拟机死机，然后一两周内什么都没有。我们还没有找到一种模式，没有发现任何可以复制或导致它的东西。在 Sun 错误数据库中搜索也没有帮助。

我们尝试了来自http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6354939 的建议解决方法 (-XX:-CMSPermGenPrecleaningEnabled -XX:-CMSConcurrentMTEnabled) 没有帮助。它似乎只是改变了导致它的线程......或者至少让我们相信。

此外，升级到 1.6.0_13 也没有帮助，并且向 Sun 提出的错误请求从未得到响应。

所以我的问题是，有没有人看到或知道要寻找什么？这可能与操作系统库有关吗？

已编辑：操作系统为 Linux，OpenSuse 在 AMD cpus 上运行（Linux 2.6.18.8-0.1-dw #3 SMP Thu Mar 15 01:21:48 GMT 2007 x86_64 x86_64 x86_64 GNU/Linux）

#
# An unexpected error has been detected by Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x062c75f5, pid=6667, tid=1090374560
#
# Java VM: Java HotSpot(TM) Server VM (11.2-b01 mixed mode linux-x86)
# Problematic frame:
# V [libjvm.so+0x2c75f5]
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
#

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

Current thread (0x081ddc00): ConcurrentGCThread [stack: 0x40f5c000,0x40fdd000] [id=6679]

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

Registers:
EAX=0x00000000, EBX=0x00000008, ECX=0x0bf5e510, EDX=0x42d6dcb0
ESP=0x40fdc150, EBP=0x40fdc168, ESI=0x40fdc200, EDI=0xa19e9640
EIP=0x062c75f5, CR2=0x0000000c, EFLAGS=0x00210206

Top of Stack: (sp=0x40fdc150)
0x40fdc150: 40fdc200 71c70000 0815a748 0815a704
0x40fdc160: a19e9640 40fdc200 40fdc198 062c74cb
0x40fdc170: 40fdc200 a19e9640 0bf5e510 0bf5e510
0x40fdc180: 080ea6f0 40fdc200 00000010 a19e9640
0x40fdc190: ad38a000 40fdc200 40fdc1c8 0629efaa
0x40fdc1a0: 40fdc200 a19e9640 00000100 00000100
0x40fdc1b0: 0815ab00 40fdc200 40fdc2b8 40fdc200
0x40fdc1c0: 080ea5f0 0815a638 40fdc2b8 062c2905

Instructions: (pc=0x062c75f5)
0x062c75e5: 53 83 ec 0c 8b 7d 0c 8b 75 08 8b 47 04 8d 58 08
0x062c75f5: 8b 53 04 89 d1 c1 f9 02 85 d2 7e 6f b8 04 00 00

Stack: [0x40f5c000,0x40fdd000], sp=0x40fdc150, free space=512k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0x2c75f5]
V [libjvm.so+0x2c74cb]
V [libjvm.so+0x29efaa]
V [libjvm.so+0x2c2905]
V [libjvm.so+0x2bb461]
V [libjvm.so+0x2c9ef5]
V [libjvm.so+0x506929]
C [libpthread.so.0+0x52ab]

【问题讨论】：

serverfault.com 仍然是私人测试版......所以我可能会很适合......在未来。
这似乎已在 Sun JDK 6u20 中得到修复。
@ReneS - "... 对 Sun 的错误请求从未返回响应。"。这是一个错误报告而不是支持请求。他们明确表示你不应该期待任何回应......现在你必须承认这一点，然后他们才会让你提交错误报告！如果您需要支持，您应该签署一份 Oracle Java 支持合同。

标签： java jvm crash jdk1.6

【解决方案1】：

我有一个非常相似的 JVM 转储。原因是 Solaris 区域中缺少内存/交换空间。在 64 位模式下运行相同的程序（即使用 Java 选项 -d64），错误更加明确：

A fatal error has been detected by the Java Runtime Environment:

java.lang.OutOfMemoryError: requested 395856 bytes for Chunk::new. Out of swap space?

Internal Error (allocation.cpp:272), pid=10847, tid=32 Error: Chunk::new

JRE version: 6.0_23-b05 Java VM: Java HotSpot(TM) 64-Bit Server VM (19.0-b09 mixed mode solaris-sparc compressed oops) If you would like to submit a bug report, please visit: @987654321@

【讨论】：

【解决方案2】：

自 6u13 以来，已经修复了几个与 GC 崩溃相关的错误。以下是一些：

6897143 - 在使用 ParallelGC 的 HeapInspection 期间压力测试崩溃。
6845368 - 大对象导致崩溃或意外异常
6840775 - 通过 1.6.0_14 的早期访问在 1.6.0_10 中看到多个 JVM 崩溃 - 可能与 GC 相关
6806226 - 可增长数组代码中的有符号整数溢出导致 JVM 崩溃

我建议至少使用 Java 6 Update 18 (u18)。

【讨论】：