Starting a modal dialog using JOptionPane.showMessageDialog()
deadlocks, with a grabbed Xserver, if it is started while a drag-n-drop
operation is in progress (it is called from invokeLater).


As part of the DragGestureListener implementation, a dragGestureRecognized
method is called when the drag starts.

This does a Thread.sleep(2000) (for example), to ensure the drag is underway.

Then it calls JOptionPane.showMessageDialog(null, new String("Click Me")

This is done with invokeLater:

SwingUtilities.invokeLater(new Runnable()
 {
        public void run() {
        JOptionPane.showMessageDialog(null, new String("Click Me"));

to be "safe": the invokeLater is run in the AWT Event Queue, and the
Dialog.show starts a new Event "pump".

However, if the mouse button was still held (drag still in progress, Xserver
still grabbed), this event pump to deal with the "show" operation will
never complete, and the app locks up.

As the X server was grabbed by the app as part of the drag operation,
the mouse and keyboard are unusable by other X clients.

Comparing a non-modal dialog: the contents of a frame cannot be drawn while
the drag is in progress. However, this is a delay rather than deadlock, as the
creation of a Frame is not a blocking call.

The same (Modal) code is fine on Windows' JDK.

Testing on Java 1.4 Beta, similar behaviour is observed but
the dialog box does draw itself, and repaints itself when necessary.
It still does not respond to mouse clicks, and the mouse still appears
"grabbed": no window manager 'move' operations are possible, for example.

Believe suspect this new bug is seen after implementing the solution for 4352221

To Reproduce:
------------
Cusomter testcase attached: SunLock.java

Any Solaris Java 2 JDK will show problems. Compile with:
javac SunLock.java
Run with:
java SunLock

Start a drag operation in the window presented, and wait (keep mouse button
depressed). A modal dialog will attempt to display.


--------------------

Further details:

Using a reference version to get a monitor cache dump
1.2.2_007 reference shows:

Monitor Cache Dump:
...
    java.lang.Class@FB8AB460/FB91DCF8: owner "AWT-Motif" (0x363d98) 1 entry
        Waiting to enter:
            "AWT-EventQueue-0" (0x300420)
...

Where:
    "AWT-Motif" (TID:0xfb8bc2b0, sys_thread_t:0x363d98, state:CW) prio=5
        at sun.awt.motif.MToolkit.run(Native Method)
        at java.lang.Thread.run(Thread.java, Compiled Code)

And:
    "AWT-EventQueue-0" (TID:0xfb8bc890, sys_thread_t:0x300420, state:MW) prio=6
        at sun.awt.motif.MComponentPeer.nativeHandleEvent(Native Method)
        at sun.awt.motif.MComponentPeer.handleEvent(MComponentPeer.java, Compiled Code)
        at java.awt.Component.dispatchEventImpl(Component.java, Compiled Code)
        at java.awt.Container.dispatchEventImpl(Container.java, Compiled Code)
        at java.awt.Window.dispatchEventImpl(Window.java, Compiled Code)
        at java.awt.Component.dispatchEvent(Component.java, Compiled Code)
        at java.awt.EventQueue.dispatchEvent(EventQueue.java, Compiled Code)
        at java.awt.EventDispatchThread.pumpOneEventForComponent(EventDispatchThread.java, Compiled
 Code)
        at java.awt.EventDispatchThread.pumpEventsForComponent(EventDispatchThread.java, Compiled C
ode)
        at java.awt.Dialog.show(Dialog.java, Compiled Code)



Similarly, 1.3.1 Production shows:

"AWT-Motif" prio=6 tid=0x1ec4d0 nid=0xe runnable [0xf4601000..0xf46019e0]
        at sun.awt.motif.MToolkit.run(Native Method)
        at java.lang.Thread.run(Thread.java:484)


and:

"AWT-EventQueue-0" prio=6 tid=0x197ba0 nid=0xc waiting for monitor entry [0xf4800000..0xf48019e0]
        at sun.awt.motif.MGlobalCursorManager.findHeavyweightUnderCursor(Native Method)
        at sun.awt.motif.MGlobalCursorManager.findHeavyweightUnderCursor(MGlobalCursorManager.java:
62)
        at sun.awt.GlobalCursorManager._updateCursor(GlobalCursorManager.java:182)
        at sun.awt.GlobalCursorManager.updateCursorImmediately(GlobalCursorManager.java:91)
        at java.awt.Container.validate(Container.java:737)
        at java.awt.Window.dispatchEventImpl(Window.java:897)
        at java.awt.Component.dispatchEvent(Component.java:2497)
        at java.awt.EventQueue.dispatchEvent(EventQueue.java:339)
        at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:131)
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:98)
        at java.awt.Dialog.show(Dialog.java:380)


We believe findHeavyweightUnderCursor wants to acquire the awt_lock.
Noting the mutex acquired at a native Solaris level, it is the AWT-Motif thread
which holds the thing the Event queue wants.

However, the AWT-Motif thread is, at a Solaris level, in a poll which does
not return.