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
