bug#69762: X11 versions of Emacs 29 on sparc fail at startup

[Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

Ali Bahrami <ali_gnu2@emvision.com> writes:

>    I'm afraid that it still fails with the same error:
>
>     % src/emacs
>     X protocol error: BadDrawable (invalid Pixmap or Window parameter) on protocol request 134
>     Serial no: 1318
>     Failing resource ID (if any): 0x43020000
>     Minor code: 14
>     This is a bug!  Please report this to bug-gnu-emacs@gnu.org!

Too bad, but see below.

> The following isn't a fix, but I've come up with
> a workaround.
>
> I was looking at the code for x_sync_init_fences() that
> we've been doing these experiments on. I noticed that
> that this code is not always used:
>
>  /* Sync fences aren't supported by the X server.  */
>   if (dpyinfo->xsync_major < 3
>       || (dpyinfo->xsync_major == 3
>           && dpyinfo->xsync_minor < 1))
>     return;
>
> Hence, the sync fence support is optional, and emacs is
> willing to run without it.
>
> It's also only compiled in when built on systems that know
> the extension, guarded by a '#ifdef HAVE_XSYNCTRIGGERFENCE'.
>
> And lastly, it's only called for non-GTK X11, which essentially
> means, only for Lucid:
>
>     xfns.c
>
>     #if defined HAVE_XSYNCTRIGGERFENCE && !defined USE_GTK \
>       && defined HAVE_CLOCK_GETTIME
>           x_sync_init_fences (f);
>     #endif
>
> So this works on Solaris 10 sparc, because those
> old X11 bits lack the sync fence extension. And it
> "works" on current Solaris GTK, because it's not used.
>
> Hence, the workaround, which is to put this at the top
> of x_sync_init_fences():
>
>   /* This feature does not work properly on sparc */
>   #ifdef __sparc
>     return;
>   #endif
>
> With that in place, Lucid emacs starts, and runs normally.
> This is clearly not a proper fix, but it is an effective
> workaround, and presumably, no worse that using emacs 28.2,
> which completely lacks sync fence support.
>
> I wonder if we might be looking at a problem with the
> sync fence extension on sparc?

That's more than likely, yes, though one wonders why Emacs is the first
program to call attention to this problem.  The only role of the
drawable parameter to SyncCreateFence is as a reference to its screen,
which is completely defeated if not even the screen's root window is
deemed valid.

> Although I now have usable way around the issue, I'm willing
> to continue with any experiments you want to try. Let me
> know...

I don't think such a drastic measure is necessary under the
circumstances.  We should (please test) put this down as a bug in the
X.Org server and install an error trap around SyncCreateFence requests,
thus:

diff --git a/src/xterm.c b/src/xterm.c
index c8a43785564..26926bc4faa 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -7292,6 +7292,7 @@ x_sync_init_fences (struct frame *f)
 	  && dpyinfo->xsync_minor < 1))
     return;
 
+  x_ignore_errors_for_next_request (dpyinfo, 0);
   output->sync_fences[0]
     = XSyncCreateFence (FRAME_X_DISPLAY (f),
 			/* The drawable given below is only used to
@@ -7303,6 +7304,7 @@ x_sync_init_fences (struct frame *f)
     = XSyncCreateFence (FRAME_X_DISPLAY (f),
 			FRAME_X_WINDOW (f),
 			False);
+  x_stop_ignoring_errors (dpyinfo, 0);
 
   XChangeProperty (FRAME_X_DISPLAY (f), FRAME_OUTER_WINDOW (f),
 		   dpyinfo->Xatom_net_wm_sync_fences, XA_CARDINAL,