Bug#1030909: Unable to run xscreensaver-demo or xscreensaver-settings

[Simon McVittie]

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