<AWT Dev> JDK-8015471 "Deadlock or infinit loop in XAWT on Ubuntu 12.04"
Christian
chsu79 at gmail.com
Thu Jul 30 14:23:54 UTC 2015
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20150730/0c342f3a/attachment.html>
More information about the awt-dev
mailing list