diff options
author | Sven Gothel <[email protected]> | 2023-10-02 19:42:42 +0200 |
---|---|---|
committer | Sven Gothel <[email protected]> | 2023-10-02 19:42:42 +0200 |
commit | f842843df2c77f5badaace6858d3336151ce0827 (patch) | |
tree | 1e0e9c6b689fccc580507f9a2809f785986466b1 /src/newt/native/bcm_vc_iv.h | |
parent | b0893eda1035bcb1c6a88e52dac6cd00dfedf696 (diff) |
Bug 1468 - SIGSEGV on use after free when destroying NEWT Window/Display via a native dispatch'ed event like key/mouse/touch input
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*.
This issue 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
is 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
+++
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.
Diffstat (limited to 'src/newt/native/bcm_vc_iv.h')
0 files changed, 0 insertions, 0 deletions