我正在研究在我的应用程序中偶尔发生的JVM崩溃。 hs_err文件包含有关崩溃的以下详细信息。
# SIGSEGV (0xb) at pc=0x065e68f4, pid=20208, tid=570166160
#
# Java VM: Java HotSpot(TM) Server VM (10.0-b23 mixed mode linux-x86)
...
# Problematic frame:
# V [libjvm.so+0x5e68f4]
...
Current thread (0x099ea800): JavaThread "Thread-315" daemon [_thread_in_vm, id=25782, stack(0x21fa3000,0x21fc1000)]
...
vm_info: Java HotSpot(TM) Server VM (10.0-b23) for linux-x86 JRE (1.6.0_07-b06), built on Jun 10 2008 01:20:15 by "java_re" with gcc 3.2.1-7a (J2SE release)
因此,这告诉我JVM在运行某些Java代码时遇到了段错误。错误日志还包含有关崩溃的线程堆栈的信息。
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0x5e68f4]
V [libjvm.so+0x1c054f]
V [libjvm.so+0x1bfef2]
V [libjvm.so+0x1bf57f]
V [libjvm.so+0x592495]
V [libjvm.so+0x365c4e]
v ~BufferBlob::Interpreter
v ~BufferBlob::Interpreter
v ~BufferBlob::Interpreter
v ~BufferBlob::Interpreter
v ~BufferBlob::Interpreter
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
v ~BufferBlob::Interpreter
v ~BufferBlob::Interpreter
v ~BufferBlob::Interpreter
v ~BufferBlob::Interpreter
v ~BufferBlob::Interpreter
J org.myapp.AppClass.getBytes()Lorg/myapp/ByteHolder;
我已经使用GDB从崩溃中连接到核心文件,并获得有关堆栈的更多详细信息。这给了我以下输出。
#5 <signal handler called>
#6 0x065e68f4 in interpretedVFrame::monitors() const ()
from /usr/java/jdk1.6.0_07/jre/lib/i386/server/libjvm.so
#7 0x061c054f in get_or_compute_monitor_info(JavaThread*) ()
from /usr/java/jdk1.6.0_07/jre/lib/i386/server/libjvm.so
#8 0x061bfef2 in revoke_bias(oopDesc*, bool, bool, JavaThread*) ()
from /usr/java/jdk1.6.0_07/jre/lib/i386/server/libjvm.so
#9 0x061bf57f in BiasedLocking::revoke_and_rebias(Handle, bool, Thread*) ()
from /usr/java/jdk1.6.0_07/jre/lib/i386/server/libjvm.so
#10 0x06592495 in ObjectSynchronizer::fast_enter(Handle, BasicLock*, bool, Thread*) ()
from /usr/java/jdk1.6.0_07/jre/lib/i386/server/libjvm.so
#11 0x06365c4e in InterpreterRuntime::monitorenter(JavaThread*, BasicObjectLock*) ()
from /usr/java/jdk1.6.0_07/jre/lib/i386/server/libjvm.so
这表明原始错误报告中列出的六个libjvm.so帧与获取Java锁有关。但是,我在org.myapp.AppClass.getBytes()中找不到任何使用任何锁的代码。
堆栈中的BufferBlob :: Interpreter行是什么意思?这些Java堆栈框架? JVM堆栈帧?是否有可能计算出这些堆栈帧中被调用的内容?
注意:请不要建议我尝试切换到较新的Hotspot JVM。我依靠CMS收集器,而且CMS收集器中没有一个最新的V1.6 Hotspot JVM足够稳定。
编辑:该文档(http://www.oracle.com/technetwork/java/javase/tsg-vm-149989.pdf)声明“v”帧是“VM生成的存根帧”。知道这意味着什么吗?
EDIT2:org.myapp.AppClass.getBytes()从DataInputStream中读取。这可能涉及以下堆栈跟踪:
AppClass.getBytes()
AppClass.readByte()
DataInputStream.readByte()
SocketInputStream.read()
SocketInputStream.read(byte[],int,int)
PlainSocketImpl.aquireFD()
这个最后的方法抓住了锁。这可能是最终调用上面列出的JVM代码的源。上面的这个堆栈有一个简洁的功能,即getBytes()下面有5个Java堆栈帧。这将与“Java框架”列表中的5行BufferBlob :: Interpreter完美匹配。
这提出了几个新问题:
EDIT3 - 这个Oracle错误看起来可能是相同/类似的错误:http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6676175
显示的堆栈跟踪不完全相同,但它提到了revoke_and_rebias中罕见的竞争条件,该条件已在6u14中修复。
EDIT4 - 赏金消息应该说“熟悉热点实施”
答案 0 :(得分:4)
VM generated stub frame
只是意味着正在执行的代码是由JVM生成的。
堆栈本身(来自gdb)显示VM正在尝试访问安全点,因为它正在撤销偏置锁。您可以在this blog中阅读有关偏向锁定的信息。这意味着某个线程已经获得了一个监视器,该监视器将该监视器偏向该线程。后来其他一些线程想要锁定,所以它必须撤销需要达到安全点的偏见(即没有线程正在执行字节代码,即停止世界)。
您的错误也可能表示在某些方法的去优化期间JVM崩溃。这意味着JVM已经优化(编译)了某些方法,但随后命中了一个代码路径,导致它需要去优化,因为编译的方法不再有效。如果没有JVM升级,你不可能找到解决方法。
您似乎有2种解决方法可能需要尝试
-XX:-UseBiasedLocking
)这两种方法都可能会对性能产生影响。
如果您能够找到可靠地重现问题的测试场景,那么这将不那么令人沮丧。
答案 1 :(得分:1)
Tom Rodriguez在hotspot-runtime-dev邮件列表中已经回答了这个问题。
http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2011-November/002592.html