Created attachment 148 [details] Demonstration of bug I put together a small JDesktop-based application which uses NEWT, and I'm finding that that I can consistently lock-up the application on a Windows platform. The problem occurs when I perform the following steps: 1. Use the mouse to rotate the gears in an internal frame that has the focus. 2. Attempt to use the mouse to rotate the gears in the internal frame which DOES NOT have focus. 3. Do anything that requires the AWT EDT. The AWT event dispatch thread is locked at this point. Looking at the thread stack traces, it looks as if the NEWT windows thread is waiting on the AWT thread to change the focus. Enabling all JOGL debugging also shows that the system is still attempting to render, as I continue to see "SwapBuffers calls: ..." messages. Internal frames do not have to be overlapping to cause the problem. Both the focused internal frame and the internal frame requesting focus have to be NewtCanvasAWT instances for the problem to occur. The problem doesn't occur when the internal frame already has focus because the requestFocusHelper doesn't perform any action. This can be seen by enabling logging of "java.awt.focus.Component". The following stack traces show that the AWT EDT is running native code, while the Display EDT is waiting for the AWT EDT to return. ---------------------------------- Name: AWT-EventQueue-0-EDT-Display_Windows_nil State: WAITING on java.awt.EventQueue$1AWTInvocationLock@6833f2 Total blocked: 232 Total waited: 1,114 Stack trace: java.lang.Object.wait(Native Method) java.lang.Object.wait(Object.java:485) java.awt.EventQueue.invokeAndWait(EventQueue.java:993) com.jogamp.newt.awt.NewtCanvasAWT$FocusAction.run(NewtCanvasAWT.java:85) com.jogamp.newt.Window.focusAction(Window.java:316) com.jogamp.newt.impl.windows.WindowsDisplay.DispatchMessages0(Native Method) com.jogamp.newt.impl.windows.WindowsDisplay.dispatchMessagesNative(WindowsDisplay.java:73) com.jogamp.newt.Display.dispatchMessages(Display.java:353) com.jogamp.newt.Display$2.run(Display.java:196) com.jogamp.newt.util.EDTUtil$EventDispatchThread.run(EDTUtil.java:212) ---------------------------------- Name: AWT-EventQueue-0 State: RUNNABLE Total blocked: 25 Total waited: 23 Stack trace: sun.awt.windows.WComponentPeer._requestFocus(Native Method) sun.awt.windows.WComponentPeer.requestFocus(WComponentPeer.java:617) java.awt.Component.requestFocusHelper(Component.java:7412) java.awt.Component.requestFocusHelper(Component.java:7373) java.awt.Component.requestFocus(Component.java:7181) com.jogamp.newt.awt.NewtCanvasAWT.requestFocusAWT(NewtCanvasAWT.java:217) com.jogamp.newt.awt.NewtCanvasAWT$FocusAction$FocusActionImpl.run(NewtCanvasAWT.java:99) java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:199) java.awt.EventQueue.dispatchEvent(EventQueue.java:597) java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269) java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184) java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174) java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169) java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161) java.awt.EventDispatchThread.run(EventDispatchThread.java:122)
Created attachment 149 [details] Patch which avoids deadlock Replacing invokeAndWait() with invokeLater() avoids deadlock. From the JavaDocs for Component "Developers must never assume that this Component is the focus owner until this Component receives a FOCUS_GAINED event".
Does it still exist Steve ? I assume we still have no unit test for this one ?
Confirmed with Steve that we fixed that bug. Sorry, no scm ref ..