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

[Ali Bahrami <ali_gnu2@emvision.com>]

On 3/15/24 6:21 PM, Po Lu wrote:
> Ali Bahrami <ali_gnu2@emvision.com> writes:
> 
>> Standing by for the next iteration. Thank you!
>>
>> - Ali
> 
> How about this?  Thanks.
> 
> diff --git a/src/xterm.c b/src/xterm.c
> index c8a43785564..c4cd9386270 100644
> --- a/src/xterm.c
> +++ b/src/xterm.c
> @@ -7297,11 +7297,11 @@ x_sync_init_fences (struct frame *f)
>   			/* The drawable given below is only used to
>   			   determine the screen on which the fence is
>   			   created.  */
> -			FRAME_X_WINDOW (f),
> +			dpyinfo->root_window,
>   			False);
>     output->sync_fences[1]
>       = XSyncCreateFence (FRAME_X_DISPLAY (f),
> -			FRAME_X_WINDOW (f),
> +		        dpyinfo->root_window,
>   			False);
>   
>     XChangeProperty (FRAME_X_DISPLAY (f), FRAME_OUTER_WINDOW (f),


    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!

-----

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?

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

Thanks!

- Ali