Bug ID: JDK-7148289 [macosx] Deadlock in sun.lwawt.macosx.CWrapper$NSScreen.visibleFrame

JDK-7148289 : [macosx] Deadlock in sun.lwawt.macosx.CWrapper$NSScreen.visibleFrame

Type: Bug
Component: client-libs
Sub-Component: java.awt
Affected Version: 7u4

Priority: P2
Status: Closed
Resolution: Fixed
OS: os_x
CPU: x86

Submitted: 2012-02-23
Updated: 2013-11-12
Resolved: 2012-05-22

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

JDK 7	JDK 8
7u6Fixed	8 b40Fixed

Related Reports

Duplicate :

JDK-2223213 - [macosx] (Native?) deadlock in DnD over Modal dialog

Description

When user starts dragging a window component in NetBeans the AWT thread stays blocked with this stacktrace:

"AWT-EventQueue-0" prio=5 tid=0x00007fa204b09000 nid=0x16794b000 runnable [0x0000000167948000]
   java.lang.Thread.State: RUNNABLE
	at sun.lwawt.macosx.CWrapper$NSScreen.visibleFrame(Native Method)
	at sun.lwawt.macosx.LWCToolkit.getScreenInsets(LWCToolkit.java:355)
	at java.awt.Window.init(Window.java:497)
	at java.awt.Window.<init>(Window.java:535)
	at java.awt.Frame.<init>(Frame.java:420)
	at java.awt.Frame.<init>(Frame.java:385)
	at javax.swing.SwingUtilities$SharedOwnerFrame.<init>(SwingUtilities.java:1756)
	at javax.swing.SwingUtilities.getSharedOwnerFrame(SwingUtilities.java:1831)
	at javax.swing.JWindow.<init>(JWindow.java:185)
	at javax.swing.JWindow.<init>(JWindow.java:137)
	at org.netbeans.core.windows.view.dnd.DragWindow.<init>(DragWindow.java:85)
	at org.netbeans.core.windows.view.dnd.DragAndDropFeedbackVisualizer.createDragWindow(DragAndDropFeedbackVisualizer.java:101)
	at org.netbeans.core.windows.view.dnd.DragAndDropFeedbackVisualizer.start(DragAndDropFeedbackVisualizer.java:132)
	at org.netbeans.core.windows.view.dnd.TopComponentDragSupport.doStartDrag(TopComponentDragSupport.java:428)
	at org.netbeans.core.windows.view.dnd.TopComponentDragSupport.eventDispatched(TopComponentDragSupport.java:353)
	at java.awt.Toolkit$SelectiveAWTEventListener.eventDispatched(Toolkit.java:2430)
	at java.awt.Toolkit$ToolkitEventMulticaster.eventDispatched(Toolkit.java:2321)
	at java.awt.Toolkit$ToolkitEventMulticaster.eventDispatched(Toolkit.java:2321)
	at java.awt.Toolkit$ToolkitEventMulticaster.eventDispatched(Toolkit.java:2321)
	at java.awt.Toolkit$ToolkitEventMulticaster.eventDispatched(Toolkit.java:2321)
	at java.awt.Toolkit$ToolkitEventMulticaster.eventDispatched(Toolkit.java:2321)
	at java.awt.Toolkit$ToolkitEventMulticaster.eventDispatched(Toolkit.java:2321)
	at java.awt.Toolkit.notifyAWTEventListeners(Toolkit.java:2280)
	at java.awt.Component.dispatchEventImpl(Component.java:4757)
	at java.awt.Container.dispatchEventImpl(Container.java:2287)
	at java.awt.Component.dispatchEvent(Component.java:4687)
	at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4832)
	at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4509)
	at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4422)
	at java.awt.Container.dispatchEventImpl(Container.java:2273)
	at java.awt.Window.dispatchEventImpl(Window.java:2713)
	at java.awt.Component.dispatchEvent(Component.java:4687)
	at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:703)
	at java.awt.EventQueue.access$000(EventQueue.java:102)
	at java.awt.EventQueue$3.run(EventQueue.java:662)
	at java.awt.EventQueue$3.run(EventQueue.java:660)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
	at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:87)
	at java.awt.EventQueue$4.run(EventQueue.java:676)
	at java.awt.EventQueue$4.run(EventQueue.java:674)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
	at java.awt.EventQueue.dispatchEvent(EventQueue.java:673)
	at org.netbeans.core.TimableEventQueue.dispatchEvent(TimableEventQueue.java:162)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:244)
	at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:163)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:151)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:147)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:139)
	at java.awt.EventDispatchThread.run(EventDispatchThread.java:97)

Related NetBeans issue:
https://www.netbeans.org/bugzilla/show_bug.cgi?id=208513

Please evaluate under what conditions method Wrapper$NSScreen.visibleFrame() can block and if this should be fixed on Java side.

Thanks!

Comments

EVALUATION Perhaps we could try to workaround this issue by caching the screen's frame/visibleFrame and not trying to re-request them every time we create a window. However, the creation of the window itself will need to be performed on the AppKit thread anyway. So it's not clear if this will ease the issue. Maybe there's a way to postpone sending a DnD event until a mouse event that initiates the drag is completely processed, or some other solution. I'm reassigning the issue to a DragAndDrop expert for further evaluation.
27-02-2012
EVALUATION I tried dragging a tool window and it hung with the stack trace as in the bug report. Also, I managed to get the full thread dump. Looks like the deadlock is happening between: "AppKit Thread" daemon prio=5 tid=0x0000000100a2a800 nid=0x7fff70556cc0 runnable [0x00007fff5fbf9000] java.lang.Thread.State: RUNNABLE at sun.awt.dnd.SunDropTargetContextPeer.postDropTargetEvent(SunDropTargetContextPeer.java:583) at sun.awt.dnd.SunDropTargetContextPeer.handleEnterMessage(SunDropTargetContextPeer.java:299) which is sending a DnD event to Java and blocks until it's processed, and the AWTEventQueue thread which is trying to dispatch a call to [NSScreen visibleFrame] to the AppKit thread. It's still unclear to me why wouldn't the code hang earlier, when calling [NSScreen frame] which is happening before (see LWCToolkit.getScreenInsets()).
27-02-2012
EVALUATION Need more information: 1. What does a "Top Component" mean? What exactly needs to be dragged in what editor? Could you please provide a step-by-step instruction (what to create, where exactly to click, etc.) to reproduce the issue? 2. The EDT alone is not enough to investigate the issue. Could you attach a full thread dump to the bug please?
27-02-2012
EVALUATION On the Mac the getScreenInsets() dispatches the execution on the main thread. On Xtoolkit we aquire the AWTLock() when calling the Toolkit.getScreenInsets() method, so it looks like it should be OK for the method to block. Otherwise a similar hang would occur on X11 as well. On the Mac we also call NSScreen.frame() just before calling the NSScreen.visibleFrame(). So it's really strange why the code didn't hang earlier since the implementations of both methods are quite identical. The only differnece is that at the lowest level they call either [NSScreen frame] or [NSScreen visibleFrame] methods, but otherwise there's no differences.
27-02-2012