Geek Answers Handbook

What does BufferBlob :: Interpreter mean in the JVM crash log?

I am studying a JVM crash that sometimes happens in my application. The hs_err file contains the following crash information.

# 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 gets into segfault when running some Java code. The error log also contains information about the stack that 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 used GDB to connect to the main file due to a crash and getting more detailed stack information. This gives me the following result.

 #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 error report were associated with a Java lock capture. However, I cannot find the code inside org.myapp.AppClass.getBytes (), which uses any locks.

What do the BufferBlob :: Interpreter lines on the stack mean? Are these Java stack frames? JVM frame stack? Is it possible to work out what is called in these stack frames?

NOTE. Please do not suggest that I try to switch to the new JVM Hotspot. I rely on the CMS builder, and none of the later versions of the V1.6 Hotspot JVM is stable enough for the CMS collector.

EDIT: This document (http://www.oracle.com/technetwork/java/javase/tsg-vm-149989.pdf) states that frame "v" is "frame created by the virtual machine." Any idea what that means?

EDIT2: org.myapp.AppClass.getBytes () reads from a DataInputStream. This may include the following stack trace:

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

This last method captures the lock. This may be the source of a possible call to the JVM code above. This stack above has a neat function that contains 5 frames of the Java stack below getBytes (). This will neatly match the 5 lines of BufferBlob :: Interpreter in the Java Frames list.

There are several new questions:

  • Is it possible that the 5 lines of BufferBlob :: Interpreter in the Native Frames section are just duplicates of the same lines in the Java Frames section?
  • Why doesn't the error log show data for these 5 frames of the stack?

EDIT3 - This Oracle error probably looks the same / similar error: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6676175

The stack trace shown is not identical, but mentions the state of the rare race in revoke_and_rebias, which was fixed at 6u14.

EDIT4 - The generosity message should say "familiar with the Hotspot implementation"

+7
source share
2 answers

Tom Rodriguez answered this question on the hotspot-runtime-dev mailing list.

http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2011-November/002592.html

+1
source

VM generated stub frame means that the executable code has been generated by the JVM.

The stack itself (from gdb) shows that the virtual machine is trying to reach safepoint because it cancels the offset lock. You can read about biased blocking in this blog . This means that some stream has acquired a monitor that is biased to monitor this stream. Later, some other thread requires blocking, so it must cancel the offset, which requires a safe place (i.e., no thread executes byte code, and also stops the world).

Your error may also indicate a JVM crash during the deoptimization of some methods. This means that the JVM has already optimized (compiled) some methods, but then got into the code path, because of which it should have been disconnected, because the compiled method is no longer valid. You are unlikely to find a fix for this without updating the JVM.

It looks like you have 2 workarounds that you can try

  • if it is controlled by an offset lock, disable it ( -XX:-UseBiasedLocking )
  • if it is caused by deoptimization, find an insulting method and tell the hot spot not to compile it first of all, instructions on how to do this on this link

Both approaches can affect performance.

NB this will be less frustrating if you can develop a test case that reliably reproduces the problem.

+4
source

More articles:


All Articles