1468 2023-10-01 19:53:20 +0200 SIGSEGV on use after free when destroying NEWT Window/Display via a native dispatch'ed event like key/mouse/touch input 2023-10-02 19:43:40 +0200 1 1 3 JogAmp Newt core 2.6.0 All all RESOLVED FIXED P2 major --- 1 sgothel sgothel DEFECT f842843df2c77f5badaace6858d3336151ce0827 --- oldest_to_newest 6905 0 sgothel 2023-10-01 19:53:20 +0200 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. 6906 1 sgothel 2023-10-02 13:09:02 +0200 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. 6907 2 sgothel 2023-10-02 13:55:50 +0200 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. ... 6908 3 sgothel 2023-10-02 19:43:40 +0200 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.