Bug ID: JDK-6384219 REGRESSION: When a breakpoint is hit from EventDispatchThread, GNOME hangs.

Versions (Unresolved/Resolved/Fixed)

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.

JDK 6
6 b77Fixed

A DESCRIPTION OF THE REGRESSION :
When I debug an application on Mustang and set a breakpoint in code the executes on the EventDispatchThread, my Linux GNOME desktop hangs when that breakpoint is hit.  This runs fine on Java 5.  I am running Fedora Core 4 Linux with the latest updates on a Sony laptop with 1Meg of memory and an ATI video card.


REPRODUCIBLE TESTCASE OR STEPS TO REPRODUCE:
  To duplicate:

1. start NetBeans 5.0 under Mustang (this shouldn't be a NetBeans  bug, since it is a pure Java app) under Linux and GNOME.
2. Create a new project of type "General->Java Project with Existing Sources", click "Next>".
3. Give the project a name and directory, click "Next>".
4. Add "/usr/java/jdk1.6.0/demo/jfc/Notepad/src" to the "Source Package Folders" list and click OK.
5. Open Notepad.java, and set a breakpoint in Notepad.OpenAction.actionPerformed() (I used line 606).
6. Click the "Debug Main Project" toolbar button to invoke Notepad (accept that it is the main class).
7. In the Notepad app, click File->Open.

Notice that the breakpoint turns green indicating it has been hit and the application suspended.  All applications on the Linux desktop, including its panels, should now be hung.

  To verify this works on Java 5, edit <NetBeans installation directory>/etc/netbeans.conf and change the "netbeans_jdkhome" property to the Java 5 installation.

RELEASE LAST WORKED:
5.0 Update 6

RELEASE TEST FAILS:
mustang-b70

APPLICATION NAME: NetBeans	APPLICATION VERSION: 5.0

SUGGESTED FIX --- XBaseWindow.java Sun Feb 26 20:25:32 2006 *************** *** 896,905 **** --- 896,908 ---- if (grabWindow != null) { grabWindow.ungrabInputImpl(); XlibWrapper.XUngrabPointer(XToolkit.getDisplay(), CurrentTime); XlibWrapper.XUngrabKeyboard(XToolkit.getDisplay(), CurrentTime); XAwtState.setGrabWindow(null); + // we need to call XFlush() here to force ungrab + // see 6384219 for details + XlibWrapper.XFlush(XToolkit.getDisplay()); } } finally { XToolkit.awtUnlock(); } } --- awt_MToolkit.c Sun Feb 26 19:57:38 2006 *************** *** 3430,3439 **** --- 3430,3440 ---- } XUngrabPointer(awt_display, CurrentTime); XUngrabKeyboard(awt_display, CurrentTime); grabbed_widget = NULL; + AWT_FLUSHOUTPUT_NOW(); AWT_UNLOCK(); }

26-02-2006

EVALUATION it looks like it is a timing between java and XServer. Swing calls action listener for menu item just after calling ungrab. Adding XFlush() to XBaseWindow.ungrabInput() fixes the problem (the same should be done in MToolkit)

26-02-2006

EVALUATION Note that this doesn't happen with standalone application - in NetBeans with exact breakpoint only. actionPerformed() invokes getFrame() with sequently find up-nearest Frame as parent. Then it should open a FileDialog over it. That dialog doesn't come up with that breakpoint and display hung but getFrame() returns correct Frame though. This might relate to menus grab. I tried it with MToolkit and it may hung or not unpredictably. This looks like a thread race. Suppose in XAWT this race just more possible. It also means we should be able to write pure AWT test that doesn't need NB.

15-02-2006

Duplicate :	JDK-6394009 - REGRESSION: breakpoint in swing code locks up gnome desktop
Relates :	JDK-6714678 - IDE (Netbeans, Eclipse, JDeveloper) Debugger hangs process on Linux