Hi Cristian,
it looks like that I've already fixed this issue as [1]
Could you please check if the problem is gone with 8u60?
[1] https://bugs.openjdk.java.net/browse/JDK-8129116 Deadlock with
multimonitor fullscreen windows.
Thanks,
Alexander.
On 07/30/2015 05:23 PM, Christian wrote:
Sorry if you dont want bug talk here, I just feel that i need to send
some information somewhere. I'm talking about
https://bugs.openjdk.java.net/browse/JDK-8015471
This exact issue happen to me quite frequently. I'm running the below
jdk version, but it has happened during 1.7.0 jdks also. The bug is
closed as not reproducable.
java version "1.8.0_45"
Java(TM) SE Runtime Environment (build 1.8.0_45-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode)
By running jstack -l on the jvm I see these threads in deadlock with
each other.
"AWT-EventQueue-0" #21 prio=6 os_prio=0 tid=0x00007fa8b05ec800
nid=0x316c waiting on condition [0x00007fa892e4f000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x00000000f064a248> (a
java.util.concurrent.locks.ReentrantLock$NonfairSync)
at
java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
at
java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:209)
at
java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285)
at sun.awt.SunToolkit.awtLock(SunToolkit.java:253)
at sun.awt.X11GraphicsDevice.getConfigVisualId(Native Method)
at
sun.awt.X11GraphicsDevice.makeDefaultConfiguration(X11GraphicsDevice.java:235)
at
sun.awt.X11GraphicsDevice.getDefaultConfiguration(X11GraphicsDevice.java:227)
- locked <0x00000000f062a418> (a java.lang.Object)
at
javax.swing.RepaintManager.getDoubleBufferMaximumSize(RepaintManager.java:1153)
at
javax.swing.RepaintManager.getVolatileOffscreenBuffer(RepaintManager.java:1035)
at
javax.swing.RepaintManager$PaintManager.paint(RepaintManager.java:1482)
at javax.swing.RepaintManager.paint(RepaintManager.java:1265)
at javax.swing.JComponent.paint(JComponent.java:1042)
at
java.awt.GraphicsCallback$PaintCallback.run(GraphicsCallback.java:39)
at
sun.awt.SunGraphicsCallback.runOneComponent(SunGraphicsCallback.java:79)
at
sun.awt.SunGraphicsCallback.runComponents(SunGraphicsCallback.java:116)
at java.awt.Container.paint(Container.java:1973)
at java.awt.Window.paint(Window.java:3912)
at javax.swing.RepaintManager$4.run(RepaintManager.java:835)
at javax.swing.RepaintManager$4.run(RepaintManager.java:807)
at java.security.AccessController.doPrivileged(Native Method)
at
java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75)
at
javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:807)
at
javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:782)
at
javax.swing.RepaintManager.prePaintDirtyRegions(RepaintManager.java:731)
at javax.swing.RepaintManager.access$1300(RepaintManager.java:64)
at
javax.swing.RepaintManager$ProcessingRunnable.run(RepaintManager.java:1720)
at
java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311)
at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:756)
at java.awt.EventQueue.access$500(EventQueue.java:97)
at java.awt.EventQueue$3.run(EventQueue.java:709)
at java.awt.EventQueue$3.run(EventQueue.java:703)
at java.security.AccessController.doPrivileged(Native Method)
at
java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:726)
at
java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201)
at
java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
at
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
at
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
at
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)
Locked ownable synchronizers:
- None
"AWT-Shutdown" #22 prio=5 os_prio=0 tid=0x00007fa8b05eb000 nid=0x316b
in Object.wait() [0x00007fa892f53000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x00000000f0649ad8> (a java.lang.Object)
at java.lang.Object.wait(Object.java:502)
at sun.awt.AWTAutoShutdown.run(AWTAutoShutdown.java:295)
- locked <0x00000000f0649ad8> (a java.lang.Object)
at java.lang.Thread.run(Thread.java:745)
Locked ownable synchronizers:
- None
"AWT-XAWT" #20 daemon prio=6 os_prio=0 tid=0x00007fa8b05c1000
nid=0x316a waiting for monitor entry [0x00007fa893054000]
java.lang.Thread.State: BLOCKED (on object monitor)
at
sun.awt.X11GraphicsDevice.getDefaultConfiguration(X11GraphicsDevice.java:227)
- waiting to lock <0x00000000f062a418> (a java.lang.Object)
at
sun.awt.X11.XWindowPeer.checkIfOnNewScreen(XWindowPeer.java:683)
at
sun.awt.X11.XDecoratedPeer.handleConfigureNotifyEvent(XDecoratedPeer.java:756)
at sun.awt.X11.XBaseWindow.dispatchEvent(XBaseWindow.java:1135)
at sun.awt.X11.XBaseWindow.dispatchToWindow(XBaseWindow.java:1090)
at sun.awt.X11.XToolkit.dispatchEvent(XToolkit.java:502)
at sun.awt.X11.XToolkit.run(XToolkit.java:611)
at sun.awt.X11.XToolkit.run(XToolkit.java:532)
at java.lang.Thread.run(Thread.java:745)
Locked ownable synchronizers:
- <0x00000000f064a248> (a
java.util.concurrent.locks.ReentrantLock$NonfairSync)
I noticed a comment from the name Denis Fokin (below) that points out
that it is dual-monitor configuration related, and I am also running a
dual-monitor setup. Could explain failure to reproduce by others?
https://youtrack.jetbrains.com/issue/IDEA-122147
From what I can see in source the "AWT-XAWT" thread takes the awt lock
in this call frame
at sun.awt.X11.XToolkit.run(XToolkit.java:611)
and the "AWT-EventQueue-0" thread is trying to take the very same lock
while lazily creating the DefaultConfiguration for the first time.
The issue seems to be timing sensitive. I have not been trying to find
a place to insert some extra delay to reproduce it every time. But I
get it about 10-20% of the times when I start our awt/swing app.
If that DefaultConfiguration could be created before AWT-XAWT gets
around to dispatching events where it holds the awt lock I believe the
issue would not occur.
Maybe our code is doing something incorrectly at startup that would
make sure that this DefaultConfiguration is not lazily created before
the fact, and that explains why this bug has gone unreproducible such
a long time by people who know what they're doing?
I hope I havent made a fool of myself and this bug is fixed already,
taking your time for no good, I know im not running the cutting jdk
edge version. I just felt I'd take some time and figure out what
actually happens when my app pops up with a gray empty window.
