Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-4484572

Modal JOptionPane.showMessageDialog locks if called during Drag-N-Drop


    • Subcomponent:
    • Resolved In Build:
    • CPU:
    • OS:
    • Verification:


      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)

          "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)

          "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
              at java.awt.EventDispatchThread.pumpEventsForComponent(EventDispatchThread.java, Compiled C
              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)


      "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:
              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.


          Issue Links



              • Assignee:
                dassunw Das Das (Inactive)
                kevinw Kevin Walls
              • Votes:
                0 Vote for this issue
                1 Start watching this issue


                • Created: