On Wed, 08 Feb 2023 at 15:31:49 -0800, H. S. Teoh wrote: > Since upgrading to 6.06+dfsg1-2, I have been unable to run > xscreensaver-settings or xscreensaver-demo.
On Fri, 10 Feb 2023 at 09:05:45 +0100, Tormod Volden wrote: > On Fri, Feb 10, 2023 at 8:54 AM Marco wrote: > > > Marco, which window manager are you using? > > > > mwm (motif window manager), on both machines. > > I can reproduce the issue after installing mwm. Some relatively straightforward steps to reproduce, for any X11 experts who can look into this but might not have an appropriate environment: * boot debian-installer 12 alpha in a virtual machine * at the tasksel menu, deselect the default GNOME desktop and choose XFCE instead (to rule out any Wayland involvement) * boot the installed system * install the mwm package * log out from XFCE * log back in, choosing mwm in the lightdm menu * right-click on the background, Debian -> Applications -> Shells -> bash * xscreensaver-settings I confirm that running xscreensaver-settings in XFCE does not exhibit this bug, but running it in mwm does (apparently reliably, so if this is a timing thing then it's one that mwm users are likely to hit in practice). Some relevant package versions for the versions I tested: libgtk-3-0 3.24.36-3 mwm 2.3.8-3 xscreensaver 6.06+dfsg1-2 xserver-xorg-core 2:21.1.7-1 To run under a debugger with debug symbols: DEBUGINFOD_URLS=https://debuginfod.debian.net gdb `command -v xscreensaver-settings` and answer y at the prompt for whether to enable debuginfod support. On Fri, 10 Feb 2023 at 10:51:21 -0800, Jamie Zawinski wrote: > Tl;dr -- it looks like GDK is attempting to call XSetInputFocus and > ignore errors from it, but it is doing it wrong. I'm not an expert on the finer points of the X11 protocol, so I'm not sure what this implies. Are you saying that this is (likely to be) the root cause of the user-visible bug here (xscreensaver-settings not starting), or are you saying that it's a secondary bug in GDK that is getting in the way of further investigation of why xscreensaver-settings doesn't start? > 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. In the VM where I reproduced this, xfce4-terminal is working fine, and some random GTK 3 apps like xfce4-about and xfce4-mouse-settings are also working normally, so there's some extra factor with xscreensaver-settings (perhaps just order of operations during startup, or perhaps X11 calls done via GTK are colliding with direct X11 calls done by xscreensaver). On Sat, 11 Feb 2023 at 09:43:24 -0800, Jamie Zawinski wrote: > You may want to report a second bug against GTK, that calling > XSynchronize (dpy, True) does not work -- it appears that GTK or GDK > are setting that to false at some time later. This surprised me, because there's only one mention of XSynchronize in the GTK 3 source code as shipped in Debian, and that's the call to XSynchronize (display_x11->xdisplay, True) in gdk/x11/gdkdisplay-x11.c when GDK_SYNCHRONIZE is used for debugging. When not debugging, GTK/GDK doesn't toggle the flag, and leaves it at its default; it never explicitly calls XSynchronize(., False). >From running under a debugger with GDK_SYNCHRONIZE=1, with a breakpoint on XSynchronize, I think this part is a bad interaction with xscreensaver's use of Xt, rather than a GDK/GTK bug: - XSynchronize is called for the first time from XOpenDisplay() when called by _gdk_x11_display_open() from gtk_init() (dpy=0x55555560a9a0 in my case); this is OK, it's just the implementation of the default. - then GDK calls XSynchronize(., True) requested by GDK_SYNCHRONIZE=1 - then AT-SPI makes another XOpenDisplay() call while discovering the accessibility bus, which again calls XSynchronize(., False), but this is a second, parallel connection (in my case dpy=0x5555556839e0) so if I understand correctly, its error handling is orthogonal to the error handling on connection 0x55555560a9a0 used by GDK/GTK/xscreensaver. This is OK, it's just the implementation of the default. - Then in xscreensaver_window_realize() -> XtDisplayInitialize(), _XtDisplayInitialize calls XSynchronize(0x55555560a9a0, False), undoing the effect of GDK_SYNCHRONIZE=1 on the connection used by GTK/GDK/xscreensaver. I think this is why GDK_SYNCHRONIZE had no effect for you. In summary, GDK's call to XSynchronize to implement GDK_SYNCHRONIZE looks correct, but is done sufficiently early that in xscreensaver-settings, Xt's call overwrites its effect. smcv