SIGSEGV on use after free of native X11 Display* at XEventsQueued in DisplayDriver.DispatchMessages0. This potentially happens when an application destroys the NEWT Window/Display from an action being called directly from DisplayDriver.DispatchMessages0 (itself), i.e. keyboard or mouse input. DisplayDriver.DispatchMessages0 stays in the event loop and the next XEventsQueued call causes a SIGSEGV due to already deleted display driver connection and hence invalid native X11 Display*. Perhaps mitigate by asking the JavaObject DisplayDriver whether it is still alive - since we might have not other means to validate the X11 DisplayDriver* after free.
This issue may also exist for other Windowing System drivers, where the native (dispatch) method sticks to a loop and still (re)uses the window or display handle. One is WindowsWindow, where touch events are looped, but such handler could have closed the window.
Querying the status of a window / display instance before dispatching might not be good enough - resource could already be GC'ed, so we also would need to query jobject status - would imply an addition Java callback +++ Instead, let's do the sweaty work of having the Java callbacks return a boolean with the value Window.isNativeValid(). This way the dispatch logic - can bail out right away w/o using the resource anymore - must be reviewed by myself due to changed Call{Void->Boolean}*(..) invocation change. This review shall resolve potential similar issues. ...
commit f842843df2c77f5badaace6858d3336151ce0827 ... This fix: Having the Java callbacks return a boolean with the value Window.isNativeValid(). This way the dispatch logic - can bail out right away w/o using the resource anymore - must be reviewed by myself due to changed Call{Void->Boolean}*(..) invocation change. This review shall resolve potential similar issues. +++ Tested on X11/Linux/GNU, Windows and MacOS with new TestDestroyGLAutoDrawableNewtAWT, which tests all destruction invocation variants.