JDK-4269666 : Kestrel-FCS-E:Drag and Drop on Windows platform causes app to freeze.
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: unknown,1.2.0,1.2.1,1.2.2_004,1.3.0
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_nt
  • CPU: x86
  • Submitted: 1999-09-08
  • Updated: 2000-10-31
  • Resolved: 2000-10-31
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.
Other
1.3.0 kestrelFixed
Related Reports
Duplicate :  
JDK-4227910 - DnD on Windows causes VM to hang [with MouseListener + CustomCursor]
Duplicate :  
JDK-4301852 - Drag and Drop Failure in 1.2.2-004
Duplicate :  
JDK-4244159 - Dropping Swing components causes application to hang
Duplicate :  
JDK-4218528 - DnD of components with enabled input methods hangs java
Duplicate :  
JDK-4278343 - Drag & Drop JVM lockup stack trace
Duplicate :  
JDK-4218499 - display of Frame in drop method of a DropTargetListener causes freeze
Duplicate :  
JDK-4269245 - Kestrel fcs_E: Drag-and-Drop causes application to hang on Windows.
Relates :  
JDK-4344767 - Drag and Drop of Files on Solaris x86 causes app to freeze while repeated dnds
Relates :  
JDK-4218517 - ctrl+mouse-press+release-crtl+drag leaves mouse unusable
Description
Kestrel-FCS-E:Drag and Drop on Windows platform causes app to freeze. It works fine on Solaris

The bug is seen only in Kestrel-FCS-E build and is not seen in Kestrel-FCS-D or any build before that.

When DnD is done on any Windows platform (Windows NT/95/98), dnd takes place, but causes the java application to freeze. It stops responding to user input and in the task manager shows up as Not Responding. The application cannot be killed by Ctrl-C in the console also.

The source code is located at /home/mukundm/bug/DnD. Copy over the files TestText.java,
DnDTarget.java,
DnDSource.java to a Windows machine, compile and run it.

Perform DnD and the application freezes up. No exceptions are thrown.
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: kestrel FIXED IN: kestrel INTEGRATED IN: kestrel VERIFIED IN: kestrel
14-06-2004
SUGGESTED FIX The following changes have been backported to JDK1.2.2 for the proposed binary sent to customer for testing: /java/jdk/1.3/ws/MASTER/src/share/classes/sun/awt/Mutex.java D 1.2 99/12/04 11:45:38 kazem 3 1 00004/00008/00039 MRs: COMMENTS: Updated copyright year and/or contents. D 1.1 99/10/26 08:49:33 dpm 1 0 00047/00000/00000 MRs: COMMENTS: date and time created 99/10/26 08:49:33 by dpm /java/jdk/1.3/ws/MASTER/src/win32/native/sun/windows/awt_Toolkit.cpp D 1.122 99/10/26 08:53:54 dpm 213 212 00035/00000/01746 MRs: COMMENTS: 4269666 : Kestrel-FCS-E:Drag and Drop on Windows platform causes app to freeze. Previously, DnD code would frequently block the AWT-Windows thread while waiting for the Java EventDispatchThread. This led to a deadlock whenever the EventDispatchThread called SendMessage in native code. Now instead of true blocking on the AWT-Windows thread, we simulate blocking by starting a new native message pump. Reviewed by: martak /java/jdk/1.3/ws/MASTER/src/win32/native/sun/windows/awt_DnDDS.cpp D 1.19 99/10/26 08:53:55 dpm 23 22 00002/00002/01773 MRs: COMMENTS: 4269666 : Kestrel-FCS-E:Drag and Drop on Windows platform causes app to freeze. Previously, DnD code would frequently block the AWT-Windows thread while waiting for the Java EventDispatchThread. This led to a deadlock whenever the EventDispatchThread called SendMessage in native code. Now instead of true blocking on the AWT-Windows thread, we simulate blocking by starting a new native message pump. Reviewed by: martak /java/jdk/1.3/ws/MASTER/src/win32/classes/sun/awt/windows/WDragSourceContextPeer.java D 1.14 99/10/26 08:53:30 dpm 20 19 00038/00027/00688 MRs: COMMENTS: 4269666 : Kestrel-FCS-E:Drag and Drop on Windows platform causes app to freeze. Previously, DnD code would frequently block the AWT-Windows thread while waiting for the Java EventDispatchThread. This led to a deadlock whenever the EventDispatchThread called SendMessage in native code. Now instead of true blocking on the AWT-Windows thread, we simulate blocking by starting a new native message pump. Reviewed by: martak /java/jdk/1.3/ws/MASTER/src/win32/classes/sun/awt/windows/WToolkit.java D 1.97 99/10/26 08:53:29 dpm 163 162 00015/00000/00836 MRs: COMMENTS: 4269666 : Kestrel-FCS-E:Drag and Drop on Windows platform causes app to freeze. Previously, DnD code would frequently block the AWT-Windows thread while waiting for the Java EventDispatchThread. This led to a deadlock whenever the EventDispatchThread called SendMessage in native code. Now instead of true blocking on the AWT-Windows thread, we simulate blocking by starting a new native message pump. Reviewed by: martak /java/jdk/1.3/ws/MASTER/src/win32/classes/sun/awt/windows/WDropTargetContextPeer.java D 1.19 99/10/26 08:53:31 dpm 24 23 00114/00100/01182 MRs: COMMENTS: 4269666 : Kestrel-FCS-E:Drag and Drop on Windows platform causes app to freeze. Previously, DnD code would frequently block the AWT-Windows thread while waiting for the Java EventDispatchThread. This led to a deadlock whenever the EventDispatchThread called SendMessage in native code. Now instead of true blocking on the AWT-Windows thread, we simulate blocking by starting a new native message pump. Reviewed by: martak build/share/minclude/sun_awt.jmk: D 1.102 99/10/26 08:55:09 dpm 240 239 00001/00000/00268 MRs: COMMENTS: 4269666 : Kestrel-FCS-E:Drag and Drop on Windows platform causes app to free Previously, DnD code would frequently block the AWT-Windows thread while waiting for the Java EventDispatchThread. This led to a deadlock whenever the EventDispatchThread called SendMessage in native code. Now instead of true blocking on the AWT-Windows thread, we simulate blocking by starting a new native message pump. Reviewed by: martak build/share/minclude/win32_awt.jmk: D 1.80 99/10/26 08:55:10 dpm 155 154 00001/00000/00264 MRs: COMMENTS: 4269666 : Kestrel-FCS-E:Drag and Drop on Windows platform causes app to freeze. Previously, DnD code would frequently block the AWT-Windows thread while waiting for the Java EventDispatchThread. This led to a deadlock whenever the EventDispatchThread called SendMessage in native code. Now instead of true blocking on the AWT-Windows thread, we simulate blocking by starting a new native message pump. Reviewed by: martak build/share/minclude/win32_awt.exp: D 1.33 99/10/26 08:55:11 dpm 44 43 00001/00000/00180 MRs: COMMENTS: 4269666 : Kestrel-FCS-E:Drag and Drop on Windows platform causes app to freeze. Previously, DnD code would frequently block the AWT-Windows thread while waiting for the Java EventDispatchThread. This led to a deadlock whenever the EventDispatchThread called SendMessage in native code. Now instead of true blocking on the AWT-Windows thread, we simulate blocking by starting a new native message pump. Reviewed by: martak carolyn.lowenthal@Eng 1999-12-14
14-12-1999
EVALUATION This bug appears to be the same as all the other Windows DnD deadlock bugs. The painting code in Kestrel-E was fixed to acquire DC's on the Window's message pump thread. So if paints occur at the same time as a DnD op, things can deadlock. The reason this occurs is that DnD has the Windows message thread blocked while attempting to synchronously call code on the Java event dispatch thread. Conversely, the paint code has the dispatch thread blocked while attempting to send a message to the Windows thread. Though the painting fix made the deadlock more likely, the solution has to be to fix the DnD code; it's synchronous upcalls are the cause of all it's deadlock problems. Any Component method or event that needs to synchronize on the Windows thread has the potential to deadlock with DnD. robi.khan@eng 1999-09-20 I've noticed that the deadlock occurs in one of two places. 1) During a drag over 2) After a drop Under no circumstances does deadlock occur if you drag from the drag source without moving over a drop target. michael.martak@Eng 1999-10-18 We suspect the source of all these problems is one line of code in WDragSourceContextPeer.dispatch(): SwingUtilities.invokeAndWait((Runnable)this); This line blocks the Windows native message pumping thread waiting for processing on the Java EventDispatchThread. Meanwhile, the EventDispatchThread has done a SendMessage in native code, and is waiting for processing on the Windows native message pumping thread. One possible solution is to "block" the Windows thread by starting a secondary message pump instead of uselessly waiting on a semaphore. If necessary, we could restrict this pump to only handle SendMessage calls. (Basically, we'll just call WaitMessage or PeekMessage(PM_NOREMOVE) in a loop; never GetMessage or PeekMessage(PM_REMOVE).) I will attempt to implement this solution now. I should know more in a few hours. david.mendenhall@eng 1999-10-18 I think I'm on the right track, but I discovered that there is a set of additional deadlock cases in WDropTargetContextPeer. The calls to 'syncLock.wait()' can also cause a deadlock. I will try applying the same solution to these calls. david.mendenhall@eng 1999-10-18 The fix does indeed eliminate the deadlocks. I currently am starting up a standard message pump loop, not a SendMessage-only loop. I am a bit worried about the correctness of this approach. In particular, we are now processing native events in a different order than before. However, the current fix, if it is correct, is probably better because it allows paint messages to go through as well. I would like to run all of the JCK Drag & Drop tests to verify the fix. If some of the JCK tests fail, then we can try the SendMessage-only loop. david.mendenhall@eng 1999-10-18 Testing has approved the fix. The fix will appear in the FCS M build. david.mendenhall@eng 1999-10-26 No regression test provided. Existing SQE tests verify fix. david.mendenhall@eng 1999-10-26
26-10-1999