On Feb 10, 2023, at 5:29 AM, Tormod Volden <debian.tor...@gmail.com> wrote: > > Here is the code around that XSetInputFocus(): > https://salsa.debian.org/gnome-team/gtk3/-/blob/debian/master/gdk/x11/gdkdisplay-x11.c#L1473
Tl;dr -- it looks like GDK is attempting to call XSetInputFocus and ignore errors from it, but it is doing it wrong. I can't find the definition of gdk_x11_display_error_trap_pop_ignored or even gdk_error_trap_pop_ignored, but assuming that they are the same code as _gdk_x11_error_handler_pop here -- https://salsa.debian.org/gnome-team/gtk3/-/blob/debian/master/gdk/x11/gdkmain-x11.c#L323 ....that code is uselessly wrong and cannot ever have worked. If you don't call XSync before calling XSetErrorHandler, you have not blocked the error. All XSetErrorHandler does it set a function pointer on the Display object, it does not guarantee that the potential error response has been received. - Set error handler A - X request B generates error - Set error handler C - X requests D - X are sent - X request Z waits for a reply, receives error B - Error handler C is called instead of error handler A Now if you only used gdk_x11_display_error_trap_push and gdk_x11_display_error_trap_pop_ignored around an X11 function that waited for a response -- a "get" function -- that would work because a read implies a flush. But XSetInputFocus does not block. GDK should be changed so that either: 1: every call to XSetInputFocus has XSync before it, or 2: every *non-blocking* X11 call inside gdk_x11_display_error_trap_push has XSync before it. I suspect that with #1 it will be easier to not miss anything. As for why this is happening in XScreenSaver -- I suspect other apps running under this WM will have this problem as well. It would be interesting to try out a few more GTK3 apps and see if the same crash happens there. But it is obviously timing related, so that might not turn up any examples. -- Jamie Zawinski • jwz.org • dnalounge.com
