ConcurrentGCThread中Java虚拟机的随机崩溃
JVM在不断变化的负载下运行internet应用程序时遇到问题。这个问题来了又去。有一天,我们看到三个虚拟机死亡,在那之后,一两周内什么都没有。我们还没有找到一个模式,没有发现任何复制或导致它的东西。此外,在Sun bug数据库中进行搜索也没有帮助 我们尝试了一个建议的解决方法(-XX:-cmsPermGenPreCleanEnabled-XX:-CMSConcurrentMTEnabled),来自 没有帮助。它似乎只是改变了导致它的线索。。。或者至少让我们相信 此外,升级到1.6.0_13也没有帮助,对Sun的错误请求从未返回响应 所以我的问题是,有没有人看到了这一点,或者知道要寻找什么?这可能与操作系统库有关吗 编辑:操作系统是Linux,OpenSuse运行在AMD CPU上(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)ConcurrentGCThread中Java虚拟机的随机崩溃,java,jvm,crash,jdk1.6,Java,Jvm,Crash,Jdk1.6,JVM在不断变化的负载下运行internet应用程序时遇到问题。这个问题来了又去。有一天,我们看到三个虚拟机死亡,在那之后,一两周内什么都没有。我们还没有找到一个模式,没有发现任何复制或导致它的东西。此外,在Sun bug数据库中进行搜索也没有帮助 我们尝试了一个建议的解决方法(-XX:-cmsPermGenPreCleanEnabled-XX:-CMSConcurrentMTEnabled),来自 没有帮助。它似乎只是改变了导致它的线索。。。或者至少让我们相信 此外,升级到1.6.0_13也没
自6u13以来,已经有几个与GC崩溃相关的错误修复。。以下是一些:
- -使用ParallelGC进行HeapInspection期间的压力测试崩溃
- -大型对象会导致崩溃或意外异常
- -通过早期访问1.6.0_14,1.6.0_10出现多个JVM崩溃-可能与GC有关
- -可增长数组代码中的有符号整数溢出导致JVM崩溃
我建议至少使用Java6Update18(u18) 我有一个非常类似的JVM转储。 原因是Solaris区域中缺少内存/交换空间。 在64位模式下运行相同的程序(即使用Java选项-d64),错误更加明确:
Java运行时环境检测到一个致命错误:
java.lang.OutOfMemoryError:为Chunk::new请求了395856字节。交换空间不足?
内部错误(allocation.cpp:272),pid=10847,tid=32
错误:Chunk::new
JRE版本:6.0_23-b05
Java虚拟机:Java热点(TM)64位服务器虚拟机(19.0-b09混合模式solaris sparc压缩oops)
如果您想提交错误报告,请访问:
serverfault.com仍然是私有测试版。。。所以我可能很适合。。。在将来。这似乎可以用Sun JDK 6u20修复。@ReneS-“…对Sun的错误请求从未返回响应。”。这是错误报告,不是支持请求。他们明确表示,您不应期待任何响应。。。现在你必须承认这一点,然后他们才会让你提交错误报告!如果您需要支持,您应该签署Oracle Java支持合同。
#
# 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]