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

[H. S. Teoh]

Package: xscreensaver
Version: 6.06+dfsg1-2
Severity: important

Since upgrading to 6.06+dfsg1-2, I have been unable to run
xscreensaver-settings or xscreensaver-demo. The main xscreensaver
binary still runs and works correctly; however, I can no longer
configure which screensavers show up except by editing .xscreensaver by
hand. So marking this as important.

Here's the typical output from xscreensaver-settings:

xscreensaver-settings: 15:24:45: X error:
xscreensaver-settings: Failed request: BadMatch (invalid parameter attributes)
xscreensaver-settings: Major opcode: 42 (X_SetInputFocus)
xscreensaver-settings: Resource id: 0x1800007
xscreensaver-settings: Serial number: 440 / 441

Here's the output from xscreensaver-settings --debug:

xscreensaver-settings: 15:25:11: DISPLAY=:0
xscreensaver-settings: 15:25:11: added "/usr/libexec/xscreensaver" to $PATH
xscreensaver-settings: 15:25:11: pref changed: GtkSpinButton
xscreensaver-settings: 15:25:11: pref changed: GtkSpinButton
xscreensaver-settings: 15:25:11: pref changed: GtkSpinButton
xscreensaver-settings: 15:25:11: pref changed: GtkSpinButton
xscreensaver-settings: 15:25:11: pref changed: GtkSpinButton
xscreensaver-settings: 15:25:11: pref changed: GtkSpinButton
xscreensaver-settings: 15:25:11: pref changed: GtkSpinButton
xscreensaver-settings: 15:25:11: pref changed: GtkCheckButton
xscreensaver-settings: 15:25:11: pref changed: GtkCheckButton
xscreensaver-settings: 15:25:11: pref changed: GtkCheckButton
xscreensaver-settings: 15:25:11: pref changed: GtkRadioButton
xscreensaver-settings: 15:25:11: pref changed: GtkRadioButton
xscreensaver-settings: 15:25:11: list selection changed
xscreensaver-settings: 15:25:11: scheduling preview "hextrail --root"
xscreensaver-settings: 15:25:11: reading /usr/share/xscreensaver/config/hextrail.xml...
xscreensaver-settings: 15:25:11: scheduling preview "hextrail --root"
xscreensaver-settings: 15:25:11: reading /usr/share/xscreensaver/config/hextrail.xml...
xscreensaver-settings: 15:25:11: scheduling preview "hextrail --root"
xscreensaver-settings: 15:25:11: select list elt 114
xscreensaver-settings: 15:25:11: scheduling preview "hextrail --root"
xscreensaver-settings: 15:25:11: reading /usr/share/xscreensaver/config/hextrail.xml...
xscreensaver-settings: 15:25:11: scheduling preview "hextrail --root"
xscreensaver-settings: 15:25:12: xscreensaver-gl-visual says the GL visual is 0x21.
xscreensaver-settings: 15:25:12: using non-default visual 0x21
xscreensaver-settings: 15:25:12: saved screenshot 0x1800010 1920x1080 for window 0x180000f 425x238+437+116

xscreensaver-settings: 15:25:12: X error:
xscreensaver-settings: Failed request: BadMatch (invalid parameter attributes)
xscreensaver-settings: Major opcode: 42 (X_SetInputFocus)
xscreensaver-settings: Resource id: 0x1800007
xscreensaver-settings: Serial number: 440 / 441

I found bug #1030659, which seems to be related to this issue (it also
has the X_SetInputFocus error), but in my case there is no segfault so I
decided to file a separate bug.

Some other information that may be pertinent:
- CPU: AMD Ryzen 7 5700G with Radeon Graphics
- GPU: Cezanne [Radeon Vega Series / Radeon Vega Mobile Series] (rev c8)
- glxinfo output: please see attached.
- Desktop environment: none, using minimal XDM + ratpoison as WM.

Possibly relevant packages:

hi ratpoison 1.4.8-2+b1 amd64 keyboard-only window manager
ii xdm 1:1.1.11-3+b2 amd64 X display manager
ii xserver-common 2:21.1.6-1 all common files used by various X servers
ii xserver-xorg-core 2:21.1.6-1 amd64 Xorg X server - core server
ii xserver-xorg-input-evdev 1:2.10.6-2+b1 amd64 X.Org X server -- evdev input driver
ii xserver-xorg-input-kbd 1:1.9.0-1+b3 amd64 X.Org X server -- keyboard input driver
ii xserver-xorg-input-libinput 1.2.1-1+b1 amd64 X.Org X server -- libinput input driver
ii xserver-xorg-input-mouse 1:1.9.3-1+b1 amd64 X.Org X server -- mouse input driver
ii xserver-xorg-video-amdgpu 22.0.0-3 amd64 X.Org X server -- AMDGPU display driver


T

--
Recently, our IT department hired a bug-fix engineer. He used to work for Volkswagen.

[Tormod Volden]

Hi, thanks for your report. Thanks also for checking for similar
existing bugs. I believe it is the same issue as in #1030659 but for
now it is better to track the reports separately. I was thinking that
if it was a real issue there must be more reports coming. I am not
able to reproduce this myself.

Would it be possible for you to build the upstream sources, without
optimization, and try it out? You shouldn't need to install any of it,
just run driver/xscreensaver-settings --debug from the build tree. And
also rename your ~/.xscreensaver so that it runs with default
settings.

Tormod

[Tormod Volden]

On Thu, Feb 9, 2023 at 10:20 AM Tormod Volden wrote:
> Would it be possible for you to build the upstream sources, without
> optimization, and try it out? You shouldn't need to install any of it,
> just run driver/xscreensaver-settings --debug from the build tree. And
> also rename your ~/.xscreensaver so that it runs with default
> settings.

Now it gets a bit complicated if we don't want to install it, but at
the same time let the built xscreensaver-settings find the
screensavers from the already installed Debian packages, we need to
set the exec-prefix. In this case do not run make install afterwards!
From unpacked upstream sources:

./configure CFLAGS="-g -O0" --exec-prefix=/usr
make -j4
driver/xscreensaver-settings --debug

Tormod

[Tormod Volden]

From searching about failing X_SetInputFocus requests, one common
cause is that the window hasn't been mapped by the window manager yet.
I notice that Teoh is using the ratpoison window manager.

Marco, which window manager are you using?

[H. S. Teoh]

On Thu, Feb 09, 2023 at 08:57:22PM +0100, Tormod Volden wrote:
> > Since upgrading to 6.06+dfsg1-2, I have been unable to run
> > xscreensaver-settings or xscreensaver-demo. The main xscreensaver
>

> >From which version did you upgrade?

5.45+dfsg1-2


T

--
Written on the window of a clothing store: No shirt, no shoes, no service.

[H. S. Teoh]

[...]

Here is the output:

--------------------------snip-----------------------
$ driver/xscreensaver-settings --debug
xscreensaver-settings: 16:11:29: DISPLAY=:0.0
xscreensaver-settings: 16:11:29: added "/usr/libexec/xscreensaver" to $PATH
xscreensaver-settings: 16:11:29: pref changed: GtkSpinButton
xscreensaver-settings: 16:11:29: pref changed: GtkSpinButton
xscreensaver-settings: 16:11:29: pref changed: GtkSpinButton
xscreensaver-settings: 16:11:29: pref changed: GtkSpinButton
xscreensaver-settings: 16:11:29: pref changed: GtkSpinButton
xscreensaver-settings: 16:11:29: pref changed: GtkSpinButton
xscreensaver-settings: 16:11:29: pref changed: GtkSpinButton
xscreensaver-settings: 16:11:29: pref changed: GtkCheckButton
xscreensaver-settings: 16:11:29: pref changed: GtkCheckButton
xscreensaver-settings: 16:11:29: pref changed: GtkCheckButton
xscreensaver-settings: 16:11:29: pref changed: GtkRadioButton
xscreensaver-settings: 16:11:29: pref changed: GtkRadioButton
xscreensaver-settings: 16:11:29: list selection changed
xscreensaver-settings: 16:11:29: scheduling preview "polytopes -root -polytope 120-cell"
xscreensaver-settings: 16:11:29: /usr/local/share/xscreensaver/config/polytopes.xml does not exist.
xscreensaver-settings: 16:11:29: scheduling preview "polytopes -root -polytope 120-cell"
xscreensaver-settings: 16:11:29: /usr/local/share/xscreensaver/config/polytopes.xml does not exist.
xscreensaver-settings: 16:11:29: scheduling preview "polytopes -root -polytope 120-cell"
xscreensaver-settings: 16:11:29: select list elt 168
xscreensaver-settings: 16:11:29: scheduling preview "polytopes -root -polytope 120-cell"
xscreensaver-settings: 16:11:29: /usr/local/share/xscreensaver/config/polytopes.xml does not exist.
xscreensaver-settings: 16:11:29: scheduling preview "polytopes -root -polytope 120-cell"
xscreensaver-settings: 16:11:29: xscreensaver-gl-visual did not report a GL visual!
Segmentation fault
--------------------------snip-----------------------

Apparently there *is* a segfault, even though it doesn't appear that way
when I run the official binaries. This looks to be the same bug as
#1030659 after all.


T

--
If it tastes good, it's probably bad for you.

[Marco]

mwm (motif window manager), on both machines.

[Tormod Volden]

On Fri, Feb 10, 2023 at 1:18 AM H. S. Teoh wrote:

> xscreensaver-settings: 16:11:29: xscreensaver-gl-visual did not report a GL visual!
> Segmentation fault
> --------------------------snip-----------------------
>
> Apparently there *is* a segfault, even though it doesn't appear that way
> when I run the official binaries. This looks to be the same bug as
> #1030659 after all.

Teoh, can you please apply the patch I posted in #1030659 to get rid
of the segfault? In your first post (with the Debian binaries)
xscreensaver-gl-visual reported 0x21, and there was no segfault. I
wonder why xscreensaver-gl-visual is giving different results. Debian
is not patching anything in this regard, although build flags can be
different in your local build. Can you please attach your config.h?
Did you install all standard build dependencies for xscreensaver?

Tormod

[Tormod Volden]

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. (Normally I use the
Marco window manager :) )

Tormod

[Marco]

What is the difference in the behaviour of the according to X?
Is it a fault of mwm or XScreensaver?

[Tormod Volden]

On Fri, Feb 10, 2023 at 9:10 AM Marco wrote:
>
> What is the difference in the behaviour of the according to X?
> Is it a fault of mwm or XScreensaver?

I think XScreensaver must wait and ensure the windows is mapped and
viewable before sending the X_SetInputFocus request to it. Whether the
fix should be in XScreensaver or a graphics library, I don't know, but
I am sure Jamie can enlighten us. The problem didn't occur with
previous XScreensaver versions. This the backtrace (break on _exit):

#3 0x000055555556eb90 in x_error (dpy=0x555555605910, error=0x7fffffffd580)
at demo-Gtk.c:4258
#4 0x00007ffff6d03734 in _XError () at /lib/x86_64-linux-gnu/libX11.so.6
#5 0x00007ffff6d00107 in () at /lib/x86_64-linux-gnu/libX11.so.6
#6 0x00007ffff6d001a5 in () at /lib/x86_64-linux-gnu/libX11.so.6
#7 0x00007ffff6d0145d in _XReply () at /lib/x86_64-linux-gnu/libX11.so.6
#8 0x00007ffff6ceb54b in XInternAtom () at /lib/x86_64-linux-gnu/libX11.so.6
#9 0x00007ffff7ef76d4 in gdk_x11_atom_to_xatom_for_display ()
at /lib/x86_64-linux-gnu/libgdk-3.so.0
#10 0x00007ffff7eeb65c in () at /lib/x86_64-linux-gnu/libgdk-3.so.0
#11 0x00007ffff7ef1989 in () at /lib/x86_64-linux-gnu/libgdk-3.so.0
#12 0x00007ffff7ef1474 in () at /lib/x86_64-linux-gnu/libgdk-3.so.0
#13 0x00007ffff7eb90e4 in gdk_display_get_event ()
at /lib/x86_64-linux-gnu/libgdk-3.so.0
#14 0x00007ffff7ef10e6 in () at /lib/x86_64-linux-gnu/libgdk-3.so.0
#15 0x00007ffff718e17d in g_main_context_dispatch ()
at /lib/x86_64-linux-gnu/libglib-2.0.so.0
--Type <RET> for more, q to quit, c to continue without paging--
#16 0x00007ffff718e400 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#17 0x00007ffff718e4a3 in g_main_context_iteration ()
at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#18 0x00007ffff7501fe5 in g_application_run ()
at /lib/x86_64-linux-gnu/libgio-2.0.so.0
#19 0x0000555555572752 in main (argc=2, argv=0x7fffffffdcc8) at demo-Gtk.c:5346

I saw a similar problem here: https://github.com/libsdl-org/SDL/issues/3949

Tormod

[Tormod Volden]

On Fri, Feb 10, 2023 at 10:08 AM Jamie Zawinski wrote:
>
> You'll need to run with -sync for backtraces of X errors to make any sense. (Seeing XInternAtom in the stack is always an indication that the backtrace is bogus.)

I have indeed tried -sync and --sync but it is not recognized by
xscreensaver-settings. How do I enable it?

>
> xscreensaver-settings doesn't do anything with focus, though, so this is still confusing.

[Jamie Zawinski]

You'll need to run with -sync for backtraces of X errors to make any sense. (Seeing XInternAtom in the stack is always an indication that the backtrace is bogus.)

xscreensaver-settings doesn't do anything with focus, though, so this is still confusing.

--
Jamie Zawinski • jwz.org • dnalounge.com

[Jamie Zawinski]

Ugh. Try adding XSynchronize (s->dpy, True); to xscreensaver_window_realize around line 4958, just after s->dpy = gdk_x11_get_default_xdisplay();

It's possible that that won't be early enough to catch it... If not, maybe this in xscreensaver_window_init --

XSynchronize (gdk_x11_get_default_xdisplay(), True);

Wayland isn't involved here, is it? xscreensaver-settings should have printed warnings if so.

[Tormod Volden]

On Fri, Feb 10, 2023 at 10:29 AM Jamie Zawinski wrote:
>
> Ugh. Try adding XSynchronize (s->dpy, True); to xscreensaver_window_realize around line 4958, just after s->dpy = gdk_x11_get_default_xdisplay();
>
> It's possible that that won't be early enough to catch it... If not, maybe this in xscreensaver_window_init --
>
> XSynchronize (gdk_x11_get_default_xdisplay(), True);

Neither of those changed the backtrace.

>
> Wayland isn't involved here, is it? xscreensaver-settings should have printed warnings if so.

No Wayland here.

[Jamie Zawinski]

On Feb 10, 2023, at 1:50 AM, Tormod Volden <debian...@gmail.com> wrote:
>
> Wait, this was different:

What is the X error if you let that continue?

[Jamie Zawinski]

> Neither of those changed the backtrace.

Hmm. Try setting breakpoints in xscreensaver_app_new, xscreensaver_app_class_init, xscreensaver_app_open, xscreensaver_app_activate, xscreensaver_app_startup, xscreensaver_dialog_init, and xscreensaver_dialog_realize and let's see whether any of those are actually being called before the X error happens. If so, try putting the XSynchronize call there. If not... the X error is happening so early that it must be a GTK or GDK bug?

[Tormod Volden]

Wait, this was different:

(gdb) bt full
#0 x_error (dpy=0x7ffff7e56460, error=0x7fffffffd610) at demo-Gtk.c:4253
#1 0x00007ffff6d03734 in _XError () at /lib/x86_64-linux-gnu/libX11.so.6
#2 0x00007ffff6d00107 in () at /lib/x86_64-linux-gnu/libX11.so.6
#3 0x00007ffff6d001a5 in () at /lib/x86_64-linux-gnu/libX11.so.6
#4 0x00007ffff6d0145d in _XReply () at /lib/x86_64-linux-gnu/libX11.so.6
#5 0x00007ffff6cfcae1 in XSync () at /lib/x86_64-linux-gnu/libX11.so.6
#6 0x00007ffff7f06f88 in gdk_x11_window_get_xid () at
/lib/x86_64-linux-gnu/libgdk-3.so.0
#7 0x000055555556d36f in launch_preview_subproc (s=0x555555749360) at
demo-Gtk.c:3576
win = 0x555555749320
p = 0x555555749400
id = 93824993337600
new_cmd = 0x555555780d10 "\300\276\267UUU"
forked = -1854788039
cmd = 0x55555599eac0 "squirtorus --root"
pr = 0x5555555dd330
window = 0x5555558a4da0
#8 0x000055555556d9eb in update_subproc_timer (data=0x555555749360)
at demo-Gtk.c:3759
s = 0x555555749360
#9 0x00007ffff718ebe8 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#10 0x00007ffff718e04e in g_main_context_dispatch () at
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#11 0x00007ffff718e400 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#12 0x00007ffff718e4a3 in g_main_context_iteration () at
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#13 0x00007ffff7501fe5 in g_application_run () at
/lib/x86_64-linux-gnu/libgio-2.0.so.0
#14 0x00005555555727a7 in main (argc=2, argv=0x7fffffffdcc8) at demo-Gtk.c:5349
s = 0x7fffffffe0db "/xscreensaver-settings"

[Tormod Volden]

> > You'll need to run with -sync for backtraces of X errors to make any sense. (Seeing XInternAtom in the stack is always an indication that the backtrace is bogus.)
>
> I have indeed tried -sync and --sync but it is not recognized by
> xscreensaver-settings. How do I enable it?

FWIW, there is a GDK_SYNCHRONIZE environment variable that makes GDK
call XSynchronize some places.

"GDK_SYNCHRONIZE If set, GDK makes all X requests synchronously. This
is a useful option for debugging, but it will slow down the
performance considerably."

[Tormod Volden]

> FWIW, there is a GDK_SYNCHRONIZE environment variable that makes GDK
> call XSynchronize some places.

This the X error backtrace with GDK_SYNCHRONIZE set. Note this is not
on Debian unstable and I couldn't install libX11 debug symbols.

(gdb) bt
#0 x_error (dpy=0x7ffff7e56460, error=0x7fffffffd560) at demo-Gtk.c:4257
#1 0x00007ffff6d03734 in _XError () at /lib/x86_64-linux-gnu/libX11.so.6
#2 0x00007ffff6d00107 in () at /lib/x86_64-linux-gnu/libX11.so.6
#3 0x00007ffff6d001a5 in () at /lib/x86_64-linux-gnu/libX11.so.6
#4 0x00007ffff6d0145d in _XReply () at /lib/x86_64-linux-gnu/libX11.so.6
#5 0x00007ffff6ceb54b in XInternAtom () at /lib/x86_64-linux-gnu/libX11.so.6
#6 0x00007ffff7ef76d4 in gdk_x11_atom_to_xatom_for_display
(atom=0x9a, display=0x555555617020) at
../../../../../gdk/x11/gdkproperty-x11.c:115
#7 gdk_x11_atom_to_xatom_for_display (display=0x555555617020,
atom=0x9a) at ../../../../../gdk/x11/gdkproperty-x11.c:96
#8 0x00007ffff7eeb65c in gdk_x11_display_translate_event
(translator=<optimized out>, display=0x555555617020,
event=0x5555559f2340, xevent=0x7fffffffd8e0) at
../../../../../gdk/x11/gdkdisplay-x11.c:1068
#9 0x00007ffff7ef1989 in _gdk_x11_event_translator_translate
(translator=0x555555617020, display=0x555555617020,
xevent=xevent@entry=0x7fffffffd8e0) at
../../../../../gdk/x11/gdkeventtranslator.c:51
#10 0x00007ffff7ef1474 in gdk_event_source_translate_event
(xevent=0x7fffffffd8e0, event_source=0x555555629b40) at
../../../../../gdk/x11/gdkeventsource.c:243
#11 _gdk_x11_display_queue_events (display=0x555555617020) at
../../../../../gdk/x11/gdkeventsource.c:341
#12 0x00007ffff7eb90e4 in gdk_display_get_event
(display=display@entry=0x555555617020) at
../../../../gdk/gdkdisplay.c:441
#13 0x00007ffff7ef10e6 in gdk_event_source_dispatch (source=<optimized
out>, callback=<optimized out>, user_data=<optimized out>) at
../../../../../gdk/x11/gdkeventsource.c:363
#14 0x00007ffff718e17d in g_main_context_dispatch () at
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#15 0x00007ffff718e400 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#16 0x00007ffff718e4a3 in g_main_context_iteration () at
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#17 0x00007ffff7501fe5 in g_application_run () at
/lib/x86_64-linux-gnu/libgio-2.0.so.0
#18 0x00005555555727e0 in main (argc=2, argv=0x7fffffffdcb8) at demo-Gtk.c:5365
(gdb)

[Tormod Volden]

And this is the XSetInputFocus call sending the offending request (on
the same system).

(gdb) bt
#0 0x00007ffff6cfb350 in XSetInputFocus () at /lib/x86_64-linux-gnu/libX11.so.6
#1 0x00007ffff7eec2c1 in _gdk_wm_protocols_filter
(xev=0x7fffffffd8e0, event=<optimized out>, data=<optimized out>) at
../../../../../gdk/x11/gdkdisplay-x11.c:1473
#2 0x00007ffff7ef104f in gdk_event_apply_filters
(xevent=xevent@entry=0x7fffffffd8e0, event=event@entry=0x555555a185e0,
window=window@entry=0x0) at ../../../../../gdk/x11/gdkeventsource.c:79
#3 0x00007ffff7ef137b in gdk_event_source_translate_event
(xevent=0x7fffffffd8e0, event_source=0x555555629340) at
../../../../../gdk/x11/gdkeventsource.c:198
#4 _gdk_x11_display_queue_events (display=0x555555616020) at
../../../../../gdk/x11/gdkeventsource.c:341
#5 0x00007ffff7eb90e4 in gdk_display_get_event
(display=display@entry=0x555555616020) at
../../../../gdk/gdkdisplay.c:441
#6 0x00007ffff7ef10e6 in gdk_event_source_dispatch (source=<optimized

out>, callback=<optimized out>, user_data=<optimized out>) at
../../../../../gdk/x11/gdkeventsource.c:363

#7 0x00007ffff718e17d in g_main_context_dispatch () at
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#8 0x00007ffff718e400 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
#9 0x00007ffff718e4a3 in g_main_context_iteration () at
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#10 0x00007ffff7501fe5 in g_application_run () at
/lib/x86_64-linux-gnu/libgio-2.0.so.0
#11 0x00005555555727e0 in main (argc=2, argv=0x7fffffffdcb8) at demo-Gtk.c:5365
(gdb)

[Tormod Volden]

Here is the code around that XSetInputFocus():
https://salsa.debian.org/gnome-team/gtk3/-/blob/debian/master/gdk/x11/gdkdisplay-x11.c#L1473

[Jamie Zawinski]

On Feb 10, 2023, at 5:29 AM, Tormod Volden <debian...@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]

See also https://github.com/mirror/libX11/blob/master/src/ErrHndlr.c#L38

[Jamie Zawinski]

I meant to say:

1: every call to *XSetErrorHandler* has XSync before it, or

[Tormod Volden]

reassign 1030909 gtk+3.0 3.24.36-3
affects 1030909 xscreensaver 6.06+dfsg1-2
thanks

OK, let's see if the gtk package maintainers can comment on this.

[Jamie Zawinski]

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.

Proof: Add this to, e.g., update_subproc_timer and run with --debug:
XSetWindowBackgroundPixmap (s->dpy, 0, 0);

A second or two after startup, this will cause an X error. Backtrace will show a stack that does not include update_subproc_timer or XSetWindowBackgroundPixmap.

Add XSynchronize (s->dpy, True); before that line. Now the backtrace is as expected.

[Tormod Volden]

For completeness, here is the backtrace at breakpoint on
XSetInputFocus, on Debian unstable with debug symbols (before
launching gdb, export DEBUGINFOD_URLS="https://debuginfod.debian.net"
).

(gdb) bt full
#0 XSetInputFocus (dpy=0x5555555fda90, focus=focus@entry=41943047,
revert_to=revert_to@entry=2, time=time@entry=0) at
../../src/SetIFocus.c:41
req = <optimized out>
#1 0x00007ffff7f3678f in gdk_x11_window_focus (window=<optimized
out>, timestamp=0) at ../../../gdk/x11/gdkwindow-x11.c:2326
display = 0x5555556110f0 [GdkX11Display]
__func__ = "gdk_x11_window_focus"
#2 0x00007ffff798cfeb in gtk_window_present_with_time
(window=0x5555556e47c0 [XScreenSaverWindow], timestamp=0) at
../../../gtk/gtkwindow.c:10611
priv = <optimized out>
widget = 0x5555556e47c0 [XScreenSaverWindow]
gdk_window = 0x55555595ac30 [GdkX11Window]
__func__ = "gtk_window_present_with_time"
#3 0x000055555557009d in xscreensaver_app_activate
(app=0x5555555da0f0 [XScreenSaverApp]) at demo-Gtk.c:5321
win = 0x5555556e47c0 [XScreenSaverWindow]
debug_p = 1
dpy = 0x5555555fda90
#4 0x00007ffff70f55a9 in _g_closure_invoke_va
(closure=closure@entry=0x5555555d4400,
return_value=return_value@entry=0x0,
instance=instance@entry=0x5555555da0f0,
args=args@entry=0x7fffffffdc30, n_params=0, param_types=0x0) at
../../../gobject/gclosure.c:895
marshal = 0x7ffff70f3b60 <g_type_class_meta_marshalv>
marshal_data = 0x90
in_marshal = 0
real_closure = 0x5555555d43e0
__func__ = "_g_closure_invoke_va"
#5 0x00007ffff710ebbf in g_signal_emit_valist
(instance=0x5555555da0f0, signal_id=8, detail=<optimized out>,
var_args=var_args@entry=0x7fffffffdc30) at
../../../gobject/gsignal.c:3456
return_accu = <optimized out>
accu = {g_type = 0x0, data = {{v_int = 0, v_uint = 0, v_long =
0, v_ulong = 0, v_int64 = 0, v_uint64 = 0, v_float = 0, v_double = 0,
v_pointer = 0x0}, {v_int = 0, v_uint = 0, v_long = 0, v_ulong = 0,
v_int64 = 0, v_uint64 = 0, v_float = 0, v_double = 0, v_pointer =
0x0}}}
accumulator = 0x0
emission = {next = 0x0, instance = 0x5555555da0f0, ihint =
{signal_id = 8, detail = 0, run_type = (G_SIGNAL_RUN_LAST |
G_SIGNAL_ACCUMULATOR_FIRST_RUN)}, state = EMISSION_RUN, chain_type =
0x5555555d2640 [XScreenSaverApp/GtkApplication/GApplication]}
instance_type = <optimized out>
emission_return = {g_type = 0x0, data = {{v_int = 0, v_uint =
0, v_long = 0, v_ulong = 0, v_int64 = 0, v_uint64 = 0, v_float = 0,
v_double = 0, v_pointer = 0x0}, {v_int = 0, v_uint = 0, v_long = 0,
v_ulong = 0, v_int64 = 0, v_uint64 = 0, v_float = 0, v_double = 0,
v_pointer = 0x0}}}
rtype = 0x4 [void]
static_scope = 0
fastpath_handler = <optimized out>
closure = <optimized out>
run_type = <optimized out>
hlist = <optimized out>
l = <optimized out>
fastpath = <optimized out>
instance_and_params = <optimized out>
signal_return_type = <optimized out>
param_values = <optimized out>
node = <optimized out>
i = <optimized out>
n_params = <optimized out>
__func__ = "g_signal_emit_valist"
#6 0x00007ffff710edbf in g_signal_emit
(instance=instance@entry=0x5555555da0f0, signal_id=<optimized out>,
detail=detail@entry=0) at ../../../gobject/gsignal.c:3606
var_args = {{gp_offset = 24, fp_offset = 48, overflow_arg_area
= 0x7fffffffdd10, reg_save_area = 0x7fffffffdc50}}
#7 0x00007ffff74ff0c3 in g_application_activate
(application=application@entry=0x5555555da0f0 [XScreenSaverApp]) at
../../../gio/gapplication.c:2312
__func__ = "g_application_activate"
#8 0x00007ffff74ff438 in g_application_real_local_command_line
(application=0x5555555da0f0 [XScreenSaverApp],
arguments=0x7fffffffdd78, exit_status=0x7fffffffdd74) at
../../../gio/gapplication.c:1148
error = 0x0
options = 0x5555555dbfa0
n_args = 1
#9 0x00007ffff74ff5c6 in g_application_run
(application=0x5555555da0f0 [XScreenSaverApp], argc=<optimized out>,
argv=<optimized out>) at ../../../gio/gapplication.c:2542
arguments = 0x5555555db710
status = -1
context = 0x5555555db770
acquired_context = <optimized out>
__func__ = "g_application_run"
#10 0x000055555557040b in main (argc=2, argv=0x7fffffffdf18) at demo-Gtk.c:5398
s = 0x7fffffffe2a6 "/xscreensaver-settings"
(gdb) c

Note that if I install an empty command (command 1, continue, end) at
the breakpoint, the crash doesn't happen. So it is timing sensitive. I
don't even know if the backtrace corresponds to the request in the
crash, it is the only occurrence of XSetInputFocus when I have a
breakpoint, but maybe it is different without. On another system I see
two occurrences before the window comes up finished.

[Tormod Volden]

I am afraid this is not reaching the attention of the gtk packagers or
is not getting much priority. Is there any workaround we can add to
xscreensaver to reduce the probability of the issue manifesting? It
apparently worked better with previous versions of xscreensaver.

Tormod

[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

[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

[Tormod Volden]

On Sun, Feb 19, 2023 at 5:22 PM Simon McVittie wrote:
> 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.

Simon, thanks a lot for investigating and upstreaming the issue.

> So I think maybe xscreensaver's own error handling is fighting with GTK's?

Actually if I just comment out the XSetErrorHandler() call in
xscreensaver_window_realize() I cannot reproduce the crash any longer
with mwm. Can those affected please try that out?

Regards,
Tormod

[Jamie Zawinski]

> 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.

Oh my god that's an absolutely insane way to go about it. I'm not sure X11 sequence numbers are even guaranteed to be in order, or increase.

Anyway, the bottom line is this: one must call XSync before calling XSetErrorHandler.

If the GTK devs refuse to add that one line change, well, good luck to you all.

[Jamie Zawinski]

> 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),

Yes.

GTK calls XSetInputFocus (for some unknown reason) and attempts to ignore errors from it (for some other unknown reason, but possibly this very one). That XSetInputFocus call is the one triggering the X error causing xscreensaver-settings to crash. Had GTK ignored the error properly, this would not happen.

> 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).

That's unfortunate, but it is all very timing-sensitive, so anything could be throwing that off.

> - 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.

This makes sense, thanks. In that case, moving the call to XSynchronize to just after the call to XtDisplayInitialize should fix that oddity, at least.

[Marco]

For other readers: Seems to be fixed in 6.06+dfsg1-3