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

[Simon McVittie]

Control: forwarded -1 https://gitlab.gnome.org/GNOME/gtk/-/issues/5607
Control: reassign -1 xscreensaver,libgtk-3-0
Control: found -1 xscreensaver/6.06+dfsg1-2
Control: found -1 libgtk-3-0/3.24.36-3

It's not clear to me whether this is an xscreensaver issue or a GTK
issue, so for now I'm marking it to appear in both packages' bug pages.
If this is a GTK issue, then it's way outside my X11 knowledge, so someone
with a deeper understanding (either on the GTK or xscreensaver side)
will have to pick it up.

On Fri, 10 Feb 2023 at 10:51:21 -0800, Jamie Zawinski wrote:
> I can't find the definition of gdk_x11_display_error_trap_pop_ignored or even gdk_error_trap_pop_ignored

They're in gdk/x11/gdkdisplay-x11.c, starting at
https://salsa.debian.org/gnome-team/gtk3/-/blob/debian/3.24.36-3/gdk/x11/gdkdisplay-x11.c#L2805
and continuing to line 3002 (ignore gdk_x11_display_set_window_scale()
in the middle, which looks unrelated).

In particular, gdk_x11_display_error_trap_pop_ignored() is basically
gdk_x11_display_error_trap_pop_internal(dpy, FALSE).

According to upstream, this code is intended to handle errors in
async operations: gdk_x11_display_error_trap_pop_internal() uses
XNextRequest() to get a sequence number for the next X11 request, and
then _gdk_x11_display_error_event() treats sequence numbers between the
start sequence number recorded when the error trap was pushed, and the
end sequence number recorded when it was popped, as having been handled
elsewhere.

If there was a bug in GTK's own async error handling that led to GTK
receiving this error report, I'd expect to be seeing an error message
starting "The program '%s' received an X Window System error", and
that's not what we're getting here. Instead, we're getting "X error:"
which looks like maybe xscreensaver's XmuPrintDefaultErrorMessage()?

So I think maybe xscreensaver's own error handling is fighting with GTK's?
My understanding is that GTK expects to be the main toolkit handling its
X11 display, and has async error handling designed to minimize the number
of XSync() calls in the critical path, so it doesn't have to freeze GUI
updates whenever it tries something that can legitimately fail; but if
xscreensaver code is doing its own lower-level X11 error processing,
then that won't be aware of GTK's async error handling, and will still
treat ignored-by-GTK errors as non-ignorable.

If possible I'd suggest that xscreensaver-the-actual-screensaver (not a
GTK program) should use its own error handling, but xscreensaver-settings
(which *is* a GTK program) should defer to GTK for its error handling.

If this has changed since xscreensaver 5.45, then that would explain why
that version worked OK (even with a similar GTK version).

> 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's a lower-level function called by the higher-level
trap_push/trap_pop, so it isn't the full story.

    smcv