JDK-4683602 : creating a DragSource causes a hang in windows 98
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 1.4.1
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_98
  • CPU: x86
  • Submitted: 2002-05-11
  • Updated: 2002-06-03
  • Resolved: 2002-05-23
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.4.1 betaFixed
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Relates :  
Description
When a DragSource is created, it causes a hang in windows 98 in build 11. This passes in build 10. java has to be killed by using ctrl+alt+del as a simple ^C does not kill it. Or, the VM has to be self destructed. This can be seen from the testcase given below.

The console output is :
[C:/work/temp] java -showversion -XX:SelfDestructTimer=1 DragSourceBug
java version "1.4.1-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1-beta-b11)
Java HotSpot(TM) Client VM (build 1.4.1-beta-b11, mixed mode)
                
Creating Drag Source
Done creating   
VM self-destructed 
[1] + Done(134) java -showversion -XX:SelfDestructTimer=1 DragSourceBug
  0xfff348e9    Abort   java

Steps to reproduce the problem :
1. Compile the source code given.
2. Run the code with build 11.
3. The code does not exit. It has to be explicitly killed or the VM self-destructed.

------------------------------BEGIN SOURCE-------------------------
import java.awt.dnd.*;

public class DragSourceBug {
        public static void main(String [] args){
                System.out.println("Creating Drag Source");
                DragSource ds = new DragSource();
                System.out.println("Done creating");
                ds = null;
        }
} 
------------------------------------END SOURCE---------------------

I am not sure if this problem is related to bug 4683091 which looks similar.

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: hopper-beta FIXED IN: hopper-beta INTEGRATED IN: hopper-beta VERIFIED IN: hopper-beta
14-06-2004

EVALUATION This sounds quite serious, so we will probably need to fix it for hopper-beta. Could be related to 4683091. ###@###.### 2002-05-14 Name: dsR10078 Date: 05/15/2002 This regression was introduced with the fix for 4623377. The toolkit shutdown hook requests the toolkit thread to quit all message loops and waits until the toolkit is disposed. The toolkit thread disposes the toolkit after all message loops are exited. The fix 4623377 changed the way the request to quit all message loops is made. Before that fix the requestor posted WM_QUIT message to the message queue. The toolkit thread processes this message and quits all message loops. With the fix for 4623377, the requestor set a boolean flag instead of posting a WM_QUIT message. The toolkit thread check this flag before getting the next message from the queue and quits the message loop. The reason for this change is that the old code fails if the request is made while the toolkit thread is in a modal loop (e.g. a system menu is active or a window is moved/resized). In this case the modal loop will ignore WM_QUIT message and the message loop will never exit. However, the new code fails if the request is made while the toolkit thread is in WaitMessage() and no messages are posted to the queue after the request is made. In this case WaitMessage() never returns, so the toolkit thread never quits the message loop and the toolkit shutdown hook never completes. For some reason, on WinNT/2000/XP WaitMessage() returns even after a message is *sent* to the toolkit thread. On Win9X WaitMessage() returns only after a message is *posted*. ###@###.### 2002-05-15 ====================================================================== Commit to fix in hopper-beta. According to 4686147, this is blocking testing on win98 and Millenium. ###@###.### 2002-05-16
16-05-2002

SUGGESTED FIX Name: dsR10078 Date: 05/15/2002 Post WM_NULL message after the request to quit a message loop is made. This message will cause WaitMessage() to return. Otherwise this message will have no effect. --- awt_Toolkit.cpp Wed May 15 15:39:18 2002 *************** *** 943,948 **** --- 943,954 ---- */ if (!AwtToolkit::IsMainThread()) { InvokeFunction(DoQuitMessageLoop, &status); + /* + * Fix for 4683602. + * Post an empty message, to wake up the toolkit thread + * if it is currently in WaitMessage(), + */ + PostMessage(WM_NULL); return; } I verified that this change resolves this bug, 4683091 and 4685004. ###@###.### 2002-05-15 ====================================================================== Name: dsR10078 Date: 05/16/2002 The previous fix is not ideal. It will fail if the toolkit thread is in WaitMessage() and QuitMessageLoop() is invoked from a different thread via InvokeFunction(). In this case WM_NULL will not be posted and WaitMessage() will not return. Currently this situation can never happen, but we should prevent it from happening in the future. The corrected fix is to post a message unconditionally (even if QuitMessageLoop() is invoked on the toolkit thread): --- awt_Toolkit.cpp Thu May 16 14:32:59 2002 *************** *** 969,974 **** --- 969,981 ---- */ m_breakMessageLoop = TRUE; m_messageLoopResult = status; + + /* + * Fix for 4683602. + * Post an empty message, to wake up the toolkit thread + * if it is currently in WaitMessage(), + */ + PostMessage(WM_NULL); } /* ###@###.### 2002-05-16 ======================================================================
16-05-2002