What does BufferBlob::Interpreter in a JVM crash log mean
Martin Hare Robertson
mchr3k at gmail.com
Mon Nov 14 07:56:54 PST 2011
This mailing list looks like the best bet to get an answer to my question.
However, please let me know if I should be posting this somewhere more
I am investigating a JVM crash which happens occasionally in my
application. The hs_err file contains the following details about the crash.
# 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)
So this tells me that the JVM hit a segfault when running some Java code.
The error log also contains information about the stack of the thread which
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
I have used GDB to connect to the core file from the crash and get more
detail about the stack. This gives me the following output.
#5 <signal handler called>
#6 0x065e68f4 in interpretedVFrame::monitors() const ()
#7 0x061c054f in get_or_compute_monitor_info(JavaThread*) ()
#8 0x061bfef2 in revoke_bias(oopDesc*, bool, bool, JavaThread*) ()
#9 0x061bf57f in BiasedLocking::revoke_and_rebias(Handle, bool, Thread*) ()
#10 0x06592495 in ObjectSynchronizer::fast_enter(Handle, BasicLock*,
bool, Thread*) ()
#11 0x06365c4e in InterpreterRuntime::monitorenter(JavaThread*,
This shows that the six libjvm.so frames listed in the original bug report
were related to grabbing a Java lock. However, I can't find any code within
org.myapp.AppClass.getBytes() which uses any locks.
1) What do the BufferBlob::Interpreter lines in the stack mean?
- Are these Java stack frames?
- JVM stack frames?
- Is it possible to work out what was being called in these stack frames?
NOTE: Please don't suggest that I try to switch to a newer Hotspot JVM. I
rely on the CMS collector and none of the more recent V1.6 Hotspot JVMs
have been stable enough with the CMS collector in the testing which I have
org.myapp.AppClass.getBytes() reads from a DataInputStream. This could
produce the following stack trace:
This final method grabs a lock. This could be the source of the eventual
call into the JVM code listed above. This stack above has the convenient
feature that there are 5 Java stack frames below getBytes(). This would
match up neatly with the 5 lines of BufferBlob::Interpreter in the list of
2) Could these 5 BufferBlob::Interpreter frames correspond to the Java
stack trace I identified above? Is it possible that the 5 lines of
BufferBlob::Interpreter under the "Native frames" section refer to the same
stack frames as the same lines under the "Java frames" section?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the hotspot-runtime-dev