Что означает BufferBlob :: Interpreter в журнале сбоев JVM?

Я исследую сбой 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 выдает ошибку segfault при запуске некоторого кода 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  
#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? Можно ли определить, что вызывается в этих кадрах стека?

ПРИМЕЧАНИЕ: Пожалуйста, не предлагайте мне пытаться переключиться на более новую JVM Hotspot. Я полагаюсь на сборщик CMS, и ни одна из более поздних JVM Hotspot V1.6 не является достаточно стабильной с сборщиком CMS.

РЕДАКТИРОВАТЬ: В этом документе (http://www.oracle.com/technetwork/java/javase/tsg-vm-149989.pdf) указано, что кадр «v» является «кадром-заглушкой, сгенерированным виртуальной машиной». Есть идеи, что это значит?

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. Это будет точно совпадать с 5 строками BufferBlob :: Interpreter в списке «Java-фреймов».

Это вызывает пару новых вопросов:

• Возможно ли, что 5 строк BufferBlob :: Interpreter в разделе «Собственные фреймы» являются просто дубликатами тех же строк в разделе «Фреймы Java» "?
• Почему в журнале ошибок не отображаются подробности для этих 5 кадров стека?

EDIT3 - Эта ошибка Oracle, вероятно, будет такой же / похожей ошибкой: http: //bugs.sun .com / bugdatabase / view_bug.do? bug_id = 6676175

Показанная трассировка стека не идентична, но в ней упоминается редкое состояние гонки в revoke_and_rebias, которое было исправлено в 6u14.

РЕДАКТИРОВАТЬ4 - В сообщении о вознаграждении должно быть указано «знаком с реализацией точки доступа»