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

1

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

SIGSEGV (0xb) at pc=0xffffffff7a045f1c

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

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 строк вниз trace и довольно общий (что означает, что через него проходит много разных действий)? Существуют ли какие-либо статические методы анализа кода, которые могут помочь? Может ли поиск по байт-коду помочь? Или мы застреваем без доступа к источнику поставщика?

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

Спасибо за любую помощь по новому пути решения этой проблемы.

  • 0
    возможно, что проблема была вызвана ОС? это сообщение "" SIGSEGV (0xb) при pc = 0xffffffff7a045f1c "пришло из веб-журнала var или syslog?
  • 0
    @ThufirHawat: сообщение из журнала фатальных ошибок, поэтому оно приходит из JVM. SIGSEGV - недопустимый доступ к памяти.
Показать ещё 1 комментарий
Теги:
fatal-error

1 ответ

1

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

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

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

Поделиться
  • 0
    Интересная техника. Я думаю, что это могло бы помочь, но изменение кода для этого было бы непростой задачей. Я надеялся узнать о том, что я мог делать в основном в автономном режиме.
  • 0
    Да. Очень интересная техника
Показать ещё 1 комментарий

Ещё вопросы

Сообщество Overcoder
Наверх
Меню