Interpreting JVM thread dump...

Thread view:

ThomasH - 19 Oct 2006 02:26 GMT

On occasion I am getting these nasty lockups in my GUI,
something must be deadlocking, or maybe I execute some
code outside of the Event Dispatcher... Using

SwingUtilities.isEventDispatchThread()

everywhere I am checking for that, and it appears
to me, that everything related to the Gui is being
executed in the proper thread only.

Once the lockup happen, I fire up SIGQUIT against JVM
to force the thread dump to stderr.

I never see in it any deadlock indication, however
I see that EDT waits for a monitor, like this:

"AWT-EventQueue-0" prio=1 tid=0x08183d08 nid=0x2808 waiting for monitor entry [8dadf000..8dadf878]
at java.awt.Component.getGraphicsConfiguration(Component.java:746)
- waiting to lock <0x90ed1ad8> (a java.awt.Component$AWTTreeLock)
at javax.swing.RepaintManager.getVolatileOffscreenBuffer(RepaintManager.java:535)
at javax.swing.JComponent.paintDoubleBuffered(JComponent.java:4727)
at javax.swing.JComponent._paintImmediately(JComponent.java:4685)
at javax.swing.JComponent.paintImmediately(JComponent.java:4488)
at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:410)
at javax.swing.SystemEventQueueUtilities$ComponentWorkRequest.run(SystemEventQueueUtilities.java

:117)

at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:189)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:478)
at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:201)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:151)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:145)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:137)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:100)

however, I am at a loss with trying to identify this "bad monitor"
owner!! Could someone give me a hint how to identify who is causing
a wait for monitor indicated as [8dadf000..8dadf878]?? The dump does
not indicate anybody using any object in this address range.

I am using jdk 1.4.2_10, its a policy issue...

Thomas

Reply to this Message

Ben_ - 19 Oct 2006 09:27 GMT

> - waiting to lock <0x90ed1ad8> (a java.awt.Component$AWTTreeLock)

You should find a thread which has "- locked <0x90ed1ad8>" in its
stacktrace.

Reply to this Message

ThomasH - 19 Oct 2006 20:31 GMT

Ben_ wrote on 19-Oct-06 01:31:

>> - waiting to lock <0x90ed1ad8> (a java.awt.Component$AWTTreeLock)
>
> You should find a thread which has "- locked <0x90ed1ad8>" in its
> stacktrace.

Well, that was easy! Thanks a lot!

Amazing what we don't see, when we are upset.
I got so fixed on the outermost monitor entry address:

"AWT-EventQueue-0" prio=1 tid=0x08183d08 nid=0x2808 waiting for monitor entry [8dadf000..8dadf878]

that I have not looked below, and the answer was served and
presented in plain sight... With this lock pointer value we
have indeed:

at java.awt.Container.addNotify(Container.java:2049)
- locked <0x90ed1ad8> (a java.awt.Component$AWTTreeLock)
...
(and many other addNotify() in the hierarchy hold this too.
...
at java.awt.Frame.addNotify(Frame.java:482)
- locked <0x90ed1ad8> (a java.awt.Component$AWTTreeLock)
at java.awt.Window.pack(Window.java:436)

And that is a perfect clue to a nonterminating loop in
my own addNotify()

Thomas

Reply to this Message

Interpreting JVM thread dump...

Free Magazines