Интерпретация аварийных файлов Java

I have a Swing application that is heavy customised with a lot of custom painting mainly on the panels and button to add gradients and round borders.

The application infrequently crashes with exactly the same error and i get hs_err_pid[0000].log

Snippet:

Java Threads: ( => current thread )
  0x032ff400 JavaThread "Thread-1" daemon [_thread_in_native, id=3452, stack(0x04660000,0x046b0000)]
  0x02b1c400 JavaThread "Keep-Alive-Timer" daemon [_thread_blocked, id=3524, stack(0x04850000,0x048a0000)]
  0x03198800 JavaThread "Poller Thread" [_thread_blocked, id=2444, stack(0x04610000,0x04660000)]
  0x032d3c00 JavaThread "ClientAPI::HttpConnection::InputStreamByteReader" [_thread_blocked, id=3672, stack(0x04ad0000,0x04b20000)]
  0x03288400 JavaThread "ClientAPI::HttpConnection" [_thread_blocked, id=4564, stack(0x04a30000,0x04a80000)]
  0x0329f400 JavaThread "ClientAPI::HttpPostConnection" [_thread_blocked, id=412, stack(0x049e0000,0x04a30000)]
  0x02a90400 JavaThread "MultiThreadedHttpConnectionManager cleanup" daemon [_thread_blocked, id=3500, stack(0x048a0000,0x048f0000)]
  0x003a9400 JavaThread "DestroyJavaVM" [_thread_blocked, id=132, stack(0x008c0000,0x00910000)]
  0x03e56800 JavaThread "Thread-7" [_thread_blocked, id=2912, stack(0x04700000,0x04750000)]
  0x03e1d800 JavaThread "TimerQueue" daemon [_thread_blocked, id=5728, stack(0x03da0000,0x03df0000)]
  0x031abc00 JavaThread "AWT-EventQueue-0" [_thread_blocked, id=2788, stack(0x036c0000,0x03710000)]
  0x0314ec00 JavaThread "AWT-Shutdown" [_thread_blocked, id=2468, stack(0x034a0000,0x034f0000)]
=>0x02fbe400 JavaThread "Java2D Disposer" daemon [_thread_in_vm, id=5836, stack(0x03450000,0x034a0000)]
  0x02a74400 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=3044, stack(0x02d20000,0x02d70000)]
  0x02a6e400 JavaThread "CompilerThread0" daemon [_thread_blocked, id=3248, stack(0x02cd0000,0x02d20000)]
  0x02a6cc00 JavaThread "Attach Listener" daemon [_thread_blocked, id=548, stack(0x02c80000,0x02cd0000)]
  0x02a6b800 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=2792, stack(0x02c30000,0x02c80000)]
  0x02a63000 JavaThread "Finalizer" daemon [_thread_blocked, id=1504, stack(0x02be0000,0x02c30000)]
  0x02a61c00 JavaThread "Reference Handler" daemon [_thread_blocked, id=3124, stack(0x02b90000,0x02be0000)]

Is there a way of interpreting this file to determine what could be wrong in my application?

Edit, added more details

From the answered so far, this article and the snipper below, i think the setting of cursors is causing these issues.

Stack: [0x03450000,0x034a0000],  sp=0x0349f860,  free space=318k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [jvm.dll+0xd2db8]

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  java.awt.Cursor.finalizeImpl(J)V+0
j  java.awt.Cursor.access$000(J)V+1
j  java.awt.Cursor$CursorDisposer.dispose()V+13
j  sun.java2d.Disposer.run()V+26
j  java.lang.Thread.run()V+11
v  ~StubRoutines::call_stub
13.10.2009 12:28:19
должна быть какая-то причина исключения вместе с трассировкой стека в файле дампа - есть ли у вас так же?
matt b 13.10.2009 12:57:53
Так что вы делаете с курсорами?
Tom Hawtin - tackline 13.10.2009 14:05:11
У меня есть панель, на которой я устанавливаю обычный курсор и курсор занятости, когда я жду действия на сервере. Я рекурсивно перебираю все компоненты, устанавливая курсор в зависимости от состояния. Я позаботился о том, чтобы не создавать их сам, вызывая Cursor.getPredefinedCursor (Cursor.WAIT_CURSOR)
n002213f 14.10.2009 04:48:33
@ n002213f - вам не нужно перебирать все компоненты и устанавливать курсор. Установка курсора на контейнер (например, JFrame) приведет к тому, что все содержащиеся в нем компоненты также будут использовать этот курсор.
Nemi 16.10.2009 14:58:06
@Nemi - отметил, что я сделал изменение
n002213f 16.10.2009 21:54:44
3 ОТВЕТА
РЕШЕНИЕ

Это очень хорошее руководство по интерпретации hs_errфайлов журналов, особенно в Windows. К сожалению, это довольно сложный процесс, но в конечном итоге он должен привести вас к проблеме.

4
13.10.2009 12:36:06
К сожалению, эта ссылка сейчас не работает.
dvlcube 11.07.2017 19:02:00

Обратите внимание, что если вы не используете JNI, то ваше приложение, независимо от того, насколько оно неправильно, не должно приводить к сбою JVM. Я бы попробовал запустить его на разных JVM и машинах, чтобы исключить ошибки JVM и проблемы с оборудованием.

1
13.10.2009 12:44:22

Если вы используете Sun JRE, эта диагностика должна дать ссылку на соответствующую страницу отчета об ошибке. http://java.sun.com/webapps/bugreport/crash.jsp

Стоит убедиться, что у вас установлена ​​новейшая JRE (6u15 / 6u16) и новейшие драйверы видеокарты.

0
13.10.2009 13:20:42
пока это хорошо, я хочу убедиться, что я установил причину сбоя и, возможно,
n002213f 13.10.2009 13:29:24
Если у них нет 6u15, у них будут известные уязвимости безопасности (по крайней мере, для ненадежного кода). Возможно, вы захотите подтолкнуть их.
Tom Hawtin - tackline 13.10.2009 14:03:49
В этом контексте я буду добиваться обновления JRE, по крайней мере, мы подписывали приложение.
n002213f 14.10.2009 04:51:08