What does BufferBlob::Interpreter in a JVM crash log mean

[Martin Hare Robertson]

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
appropriate.

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
crashed.

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;

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 ()
   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

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
done.
org.myapp.AppClass.getBytes() reads from a DataInputStream. This could
produce the following stack trace:

AppClass.getBytes()
AppClass.readByte()
DataInputStream.readByte()
SocketInputStream.read()
SocketInputStream.read(byte[],int,int)
PlainSocketImpl.aquireFD()

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
"Java frames".

___

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...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20111114/9e35ba0c/attachment-0001.html