JDK-8006941 : [macosx] Deadlock in drag and drop
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 7u40,8
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: os_x
  • Submitted: 2013-01-25
  • Updated: 2014-10-15
  • Resolved: 2013-04-05
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.
7u40Fixed 8 b86Fixed
Related Reports
Duplicate :  
Duplicate :  
Relates :  
A deadlock could occur while dragging. The Appkit thread makes a call to Java on dragMouseMoved event which calls some SwingUtilities methods which get clocked on an AWTTreeLock. EventDispatchThread sometimes tries to synchronously perform a selector on the Appkit thread and a deadlock occurs. 

The simplest found way to reliably reproduce this issue is to start netbeans on JDK8 and try to drag a tab. After some time the netbeans would hang.
Its hard to create a reliable regression test, because the deadlock occurs only in huge applications like Netbeans and it's a result of the thread-race.

Since probablity to hit this issue dramatically increased for customers, SQE gives OK to take this

7u40-critical-request justification: This bug fix is needed because the code in jdk7u40 is changed a lot, so the probability of the deadlock to occur increased. For example JDK-8017625 was considered to be a regression due to this increase in probability. In JDK-8 this caused netbeans to hang on DnD quite often, so netbeans could hang in JDK-7 as well, but it's impossible to say for sure, because it's a thread race. The issue was fixed in JDK-8 quite a long time ago, no regressions were found. The issue affects performing any synchronous calls during DnD, which is quite likely to be used in customer code. Reviewed by Anthony Petrov and Sergey Bylokhov.

Just for FYI: JDK-8017625 [macosx] Lock-up on AWTTreeLock (HiDPI) - closed as as duplicate of this one.

From SQE point of view it will demand too much testing effort to take this fix so late in ATR test cycle. SQE regect this request and can reconsider their opinion only in case there is a strong business reason to take this. Currently this issue seems to be old bug and should not be addressed in build #4 of ATR.

Need SQE-OK before this can be approved.

EVALUATION: The bug is reproducible if a drag-image is set. To fix it some logic should be moved form Appkit thread to EDT