I generated a native thread dump via sample -- there is some sort
of thread
wait happening wrt that setBounds call, though I'm not sure how to
interpret
any of this:
I'm stripping the dumps down to the minimum amount for context.
Analysis of sampling pid 1646 every 10.000000 milliseconds
Call graph:
391 Thread_0e0b
...
this thread is the AppKit thread, it is hosting the CFRunLoop:
which then calls into the JVM, calling an AWT method.
391 CallBooleanMethod
Switching to the Java stack trace, reordered to bottom-to-top to
match the native trace order ...
"AWT-AppKit" daemon prio=5 tid=0x0030f670 nid=0xa000b2a4 waiting
for monitor
entry [bfffc000..bfffe230]
at java.awt.Window.isFocusableWindow(Window.java:1431)
at javax.swing.SortingFocusTraversalPolicy.getDefaultComponent
(SortingFocusTraversalPolicy.java:391)
at javax.swing.LayoutFocusTraversalPolicy.getFirstComponent
(LayoutFocusTraversalPolicy.java:143)
at javax.swing.SortingFocusTraversalPolicy.getFirstComponent
(SortingFocusTraversalPolicy.java:331)
at javax.swing.SortingFocusTraversalPolicy.enumerateAndSortCycle
(SortingFocusTraversalPolicy.java:87)
at javax.swing.SortingFocusTraversalPolicy.enumerateCycle
(SortingFocusTraversalPolicy.java:156)
at java.awt.Container.getComponents(Container.java:248)
- waiting to lock <0x7d31e60> (a java.awt.Component$AWTTreeLock)
at java.awt.Container.getComponents_NoClientCode(Container.java:255)
This last method attempts to synchronize on the AWTTreeLock, which is
held by the AWT Event Dispatch Thread:
(this is a standard Java thread dump, most recent frame at the start):
"AWT-EventQueue-0" prio=6 tid=0x003146b0 nid=0x2121000 runnable
[f0db8000..f0dbbb20]
at apple.awt.ComponentModel._setBounds(Native Method)
at apple.awt.ComponentModel.setBounds(ComponentModel.java:183)
at java.awt.Component.reshape(Component.java:1705)
- locked <0x7d31e60> (a java.awt.Component$AWTTreeLock)
at java.awt.Component.setBounds(Component.java:1664)
at java.awt.Component.resize(Component.java:1601)
at java.awt.Component.setSize(Component.java:1593)
at java.awt.Component.resize(Component.java:1622)
at java.awt.Component.setSize(Component.java:1614)
at java.awt.Window.pack(Window.java:438)
at cl.ui.widgets.tooltip.JITTooltip$SizableEditorPane.setText
(Unknown Source)
at cl.ui.widgets.tooltip.JITTooltip.setVisible(Unknown Source)
at cl.ui.modules.grapher.GraphingGridPanel.setWindowVisible
(Unknown Source)
which clearly shows it holding the AWTTreeLock. In the native stack
trace (I figure it to be Thread_1903):
it is waiting for a native pthread mutex. Assuming that CWindow is a
native AWT implementation helper class, and given that most Cocoa
windowing functions must be done from the AppKit thread, I'm guessing
that CWindow has queued the setFrame operation up for the AppKit
thread to perform, and is awaiting completion. Unfortunately, that
will never happen because the AppKit thread is waiting for the
AWTTreeLock held by this thread. It is a classic deadlock, but
involving a native pthread mutex in the AWT implementation that is
not readily visible.
I would say that this is Apple's bug, and that they probably didn't
intend to attempt to acquire the AWTTreeLock from the AppKit thread.
I always find it frustrating to deal with operations that must be
done on the Swing thread and operations that must be done on the
AppKit thread -- I do not envy them the task of interfacing the Swing
API to AppKit. I would love it if Apple could change the
implementation architecture so that the AppKit thread *is* the AWT
Event Dispatch Thread, but I'm sure that they had good reasons for
separating them.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden
