Как восстановить транзакцию из дампа потока

Question

У нас возникла проблема, когда наша JVM (HotSpot на Weblogic) завершается с фатальной ошибкой.

SIGSEGV (0xb) at pc=0xffffffff7a045f1c

Мы проанализировали и повторно проанализировали журналы фатальных ошибок ( Oracle: поиск и устранение неисправностей в журнале фатальных ошибок). Журнал ошибок включает в себя поток, работающий во время ошибки, и ее трассировку (первые три строки ниже, считывая трассировку.) Трасса одинакова каждый раз, когда происходит фатальная ошибка.

J  com.bea.wsrp.producer.container.ServletRequestImpl.setHeaders(Ljava/util/Map;Ljava/util/LinkedHashMap;Ljava/lang/String;)V
j  com.bea.wsrp.producer.container.RequestFactory.createServletRequest(Ljavax/servlet/http/HttpServletRequest;Lcom/bea/wsrp/model/markup/IRuntimeContext;Lcom/bea/wsrp/model/markup/IMarkupParams;Lcom/bea/wsrp/producer/handlers/ServiceHandler$InvocationType;)Lcom/bea/wsrp/producer/container/ServletRequestImpl;+213
j  com.bea.wsrp.producer.container.RequestFactory.createServletRequest(Ljavax/servlet/http/HttpServletRequest;Lcom/bea/wsrp/model/markup/IRuntimeContext;Lcom/bea/wsrp/model/markup/IMarkupParams;Lcom/bea/wsrp/model/markup/state/IOpaqueState;Lcom/bea/wsrp/model/markup/INavigationalContext;Lcom/bea/wsrp/producer/handlers/ServiceHandler$InvocationType;)Lcom/bea/wsrp/producer/container/ServletRequestImpl;+5

Мой вопрос, учитывая трассировку стека и наш исходный код, как мы можем выяснить действие, необходимое (или часть кода для более тщательного тестирования), чтобы воссоздать эту проблему, когда последняя часть нашего кода, которая выполнялась на ~80 строк ниже трассировка и довольно общая (имеется в виду множество различных действий, проходящих через нее)? Существуют ли методы статического анализа кода, которые могут помочь? Может ли поиск по байт-коду помочь? Или мы застряли без доступа к источнику поставщика?

Тестирование методом проб и ошибок (включая наши стандартные скрипты производительности / функциональности) не смогло воссоздать проблему или даже использовать метод setHeaders (верхняя строка приведенной выше трассировки).

Спасибо за любую помощь по новому подходу к этой проблеме.

Answer 1

Если вы имеете в виду воссоздать то же состояние потока, которое вы не знаете, каким оно было, когда оно умерло, вы можете использовать Thread.currentThread().setName(...)

Некоторые люди используют это для установки информации о состоянии потока в имени потока, чтобы последующий анализ дампа стека мог дать вам некоторую информацию о состоянии, например, имя потока может быть чем-то вроде:

thread [abc] values [tx=1234, state=state1, user=someuser, starttime=123456]