I tried to reproduce it, first by starting my app 20 times using this version. Five times I got a gray window.
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) Then the same test on this version, and success all 20 times! java version "1.8.0_60-ea" Java(TM) SE Runtime Environment (build 1.8.0_60-ea-b25) Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode) Now it could be luck that it didnt happen, but I also see what you have done there, by releasing the awtLock in the XPeerWindow while getDefaultConfig goes for the other lock that deadlocked. Thanks for a nice fix! On Thu, Jul 30, 2015 at 6:41 PM, Alexander Zvegintsev < alexander.zvegint...@oracle.com> wrote: > 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. >> >> >> >> >> >> >> >
