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

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

[ali_gnu2]

Hello,

    I maintain the the GNU emacs delivered with the
Solaris OS:

     https://github.com/oracle/solaris-userland/tree/master/components/emacs

We're still at version 28.2. It's getting long in the
tooth, so I recently tried to move to 29.2. There were no
issues on x86, but on sparc, I see display problems with
both the gtk (emacs-gtk) and lucid (emacs-x) versions that
prevent it from running.

I double checked version 28.2, which we are currently
delivering, and it has no problem. Then, I built 29.1,
and it shows the same issues as 29.2. It seems that
something was introduced early in the 29 series.

With the GTK version, I see 3 different failures on repeated
attempts:

1)

     % emacs-gtk
     Connection lost to X server 'localhost:10.0'
     When compiled with GTK, Emacs cannot recover from X disconnects.
     This is a GTK bug: https://gitlab.gnome.org/GNOME/gtk/issues/221
     For details, see etc/PROBLEMS.
     Fatal error 6: Aborted
     Backtrace:
     /usr/bin/emacs-gtk'emacs_backtrace+0x50 [0x1ffe749825f2ac]
     /usr/bin/emacs-gtk'terminate_due_to_signal+0xb4 [0x1ffe749822f804]
     /usr/bin/emacs-gtk'emacs_abort+0x8 [0x1ffe74982609c4]
     /usr/bin/emacs-gtk'x_connection_closed+0x3cc [0x1ffe74981efd54]
     /usr/bin/emacs-gtk'x_io_error_quitter+0x3c [0x1ffe74981f00f0]
     /usr/lib/sparcv9/libX11.so.4.0.0'_XIOError+0x74 [0x1ffe74904f8034]
     /usr/lib/sparcv9/libX11.so.4.0.0'_XReply+0x360 [0x1ffe74904f3bf0]
     /usr/lib/sparcv9/libXi.so.5.0.0'XIGetSelectedEvents+0x84 [0x1ffe748ed17044]
     /usr/bin/emacs-gtk'Fx_create_frame+0x17b4 [0x1ffe74982172fc]
     /usr/bin/emacs-gtk'funcall_subr+0x120 [0x1ffe74982e6f58]
     /usr/bin/emacs-gtk'exec_byte_code+0x52c [0x1ffe74983470e0]
     /usr/bin/emacs-gtk'Ffuncall+0x108 [0x1ffe74982e37d4]
     /usr/bin/emacs-gtk'Fapply+0x378 [0x1ffe74982e3c98]
     /usr/bin/emacs-gtk'funcall_subr+0xa8 [0x1ffe74982e6ee0]
     /usr/bin/emacs-gtk'exec_byte_code+0x52c [0x1ffe74983470e0]
     /usr/bin/emacs-gtk'apply_lambda+0xd4 [0x1ffe74982ea734]
     /usr/bin/emacs-gtk'eval_sub+0x630 [0x1ffe74982e88c0]
     /usr/bin/emacs-gtk'Feval+0x60 [0x1ffe74982ebb2c]
     /usr/bin/emacs-gtk'internal_condition_case+0x78 [0x1ffe74982e1bbc]
     /usr/bin/emacs-gtk'top_level_1+0x40 [0x1ffe7498233bd0]
     /usr/bin/emacs-gtk'internal_catch+0x40 [0x1ffe74982e1ae8]
     /usr/bin/emacs-gtk'command_loop+0xd8 [0x1ffe749823241c]
     /usr/bin/emacs-gtk'recursive_edit_1+0xb8 [0x1ffe7498237d4c]
     /usr/bin/emacs-gtk'Frecursive_edit+0x124 [0x1ffe7498238274]
     /usr/bin/emacs-gtk'main+0x1f28 [0x1ffe7498231770]
     /usr/bin/emacs-gtk'_start+0x64 [0x1ffe74980c5c04]
     Abort (core dumped)

     Note that I don't believe that X disconnects are involved.
     This happened immediately at startup.

2)

     % emacs-gtk
     [xcb] Unknown sequence number while processing queue
     [xcb] You called XInitThreads, this is not your fault
     [xcb] Aborting, sorry about that.
     Assertion failed: !xcb_xlib_threads_sequence_lost, file /builds/ulhg/mrcarson-trunk_166/components/x11/lib/libX11/libX11-1.8.7/src/xcb_io.c, line 278, function poll_for_event
     Fatal error 6: Aborted
     Backtrace:
     /usr/bin/emacs-gtk'emacs_backtrace+0x50 [0x1fffec39a5f2ac]
     /usr/bin/emacs-gtk'terminate_due_to_signal+0xb4 [0x1fffec39a2f804]
     /usr/bin/emacs-gtk'handle_fatal_signal+0x8 [0x1fffec39a609b0]
     /usr/bin/emacs-gtk'deliver_fatal_thread_signal+0x98 [0x1fffec39a5d4b8]
     /lib/sparcv9/libc.so.1'__sighndlr+0xc [0x1fffec392c6410]
     /lib/sparcv9/libc.so.1'call_user_handler+0x400 [0x1fffec392b8cb8]
     /lib/sparcv9/libc.so.1'sigacthandler+0xd0 [0x1fffec392b90a8]
     /lib/sparcv9/libc.so.1'__lwp_sigqueue+0x8 [0x1fffec392cb528]
     /lib/sparcv9/libc.so.1'abort+0xb4 [0x1fffec391e5154]
     /lib/sparcv9/libc.so.1'_assert_c99+0x64 [0x1fffec391e5ffc]
     /usr/lib/sparcv9/libX11.so.4.0.0'poll_for_event+0x1fc [0x1fffec31cf2a8c]
     /usr/lib/sparcv9/libX11.so.4.0.0'poll_for_response+0x2c [0x1fffec31cf2b2c]
     /usr/lib/sparcv9/libX11.so.4.0.0'_XEventsQueued+0x7c [0x1fffec31cf2e8c]
     /usr/lib/sparcv9/libX11.so.4.0.0'XFlush+0x1c [0x1fffec31cba45c]
     /usr/bin/emacs-gtk'x_set_icon_type+0x70 [0x1fffec39a0c640]
     /usr/bin/emacs-gtk'gui_set_frame_parameters_1+0x1800 [0x1fffec398e0028]
     /usr/bin/emacs-gtk'gui_default_parameter+0x58 [0x1fffec398e55e8]
     /usr/bin/emacs-gtk'Fx_create_frame+0xf20 [0x1fffec39a16a68]
     /usr/bin/emacs-gtk'funcall_subr+0x120 [0x1fffec39ae6f58]
     /usr/bin/emacs-gtk'exec_byte_code+0x52c [0x1fffec39b470e0]
     /usr/bin/emacs-gtk'Ffuncall+0x108 [0x1fffec39ae37d4]
     /usr/bin/emacs-gtk'Fapply+0x378 [0x1fffec39ae3c98]
     /usr/bin/emacs-gtk'funcall_subr+0xa8 [0x1fffec39ae6ee0]
     /usr/bin/emacs-gtk'exec_byte_code+0x52c [0x1fffec39b470e0]
     /usr/bin/emacs-gtk'apply_lambda+0xd4 [0x1fffec39aea734]
     /usr/bin/emacs-gtk'eval_sub+0x630 [0x1fffec39ae88c0]
     /usr/bin/emacs-gtk'Feval+0x60 [0x1fffec39aebb2c]
     /usr/bin/emacs-gtk'internal_condition_case+0x78 [0x1fffec39ae1bbc]
     /usr/bin/emacs-gtk'top_level_1+0x40 [0x1fffec39a33bd0]
     /usr/bin/emacs-gtk'internal_catch+0x40 [0x1fffec39ae1ae8]
     /usr/bin/emacs-gtk'command_loop+0xd8 [0x1fffec39a3241c]
     /usr/bin/emacs-gtk'recursive_edit_1+0xb8 [0x1fffec39a37d4c]
     /usr/bin/emacs-gtk'Frecursive_edit+0x124 [0x1fffec39a38274]
     /usr/bin/emacs-gtk'main+0x1f28 [0x1fffec39a31770]
     /usr/bin/emacs-gtk'_start+0x64 [0x1fffec398c5c04]
     Abort (core dumped)

3)

     Sometimes, this clobbers the state of my video card, leaving
     me with a black screen with a large white square in the upper
     left corner. When this happens, I log in remotely, and using
     ps, it appears that my desktop is still running, so the X server
     is unaware that the video hardware has been whacked. I can only
     assume that a bad request is not being caught by the X11 server,
     which is likely a second bug.

With the Lucid version, I normally get this result, after
a long pause:

     % emacs-x

     Connection lost to X server 'localhost:10.0'

The fact that both the plain X11, and GTK, versions, have
problems seems to point at some generic non-toolkit specific
X code. Perhaps this is an endian issue (x86 works fine), or
maybe there's some uninitialized data involved.

I asked Rainer Orth, who I work with on Solaris gcc issues, and
who I know is also an emacs user, and he was able to confirm the
same issues, using a different X server:

     >> Given that I'm still on 27.1.90/28.2 myself, I didn't.  On the sparc
     >> side, I primarily use emacs to run gdb, which I haven't done in a
     >> while.  I can give it a whirl, though.
     >
     > here's what I found: I configured emacs with
     >
     > configure \
     > 	'CFLAGS=-g3 -O2 -m64' \
     >         --prefix=/vol/gnu \
     >         --with-gif=ifavailable
     >         PKG_CONFIG_PATH=/usr/lib/64/pkgconfig:/usr/lib/64/pkgconfig:/usr/share/pkgconfig
     >
     > and built it with the bundled gcc 13.2.0.  Started just fine with emacs
     > -nw (to confirm the basics), but then I started it remotely from my
     > ThinLinc session at work (the thin client we use): that resulted in an
     > immediate SEGV of Xvnc and termination of the session.  I'm glad I
     > didn't try this from my session at home 😉
     >
     > The Xvnc backtrace is like this:
     >
     > (EE)
     > (EE) Backtrace:
     > (EE) 0: /opt/thinlinc/libexec/Xvnc (xorg_backtrace+0x41) [0x76a2f1]
     > (EE) 1: /opt/thinlinc/libexec/Xvnc (0x400000+0x36d909) [0x76d909]
     > (EE) 2: /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f7341b61000+0x14420)
     > [0x7f7341b75420]
     > (EE) 3: /lib/x86_64-linux-gnu/libc.so.6 (0x7f73416d1000+0x18bb38)
     > [0x7f734185cb38]
     > (EE) 4: /opt/thinlinc/libexec/Xvnc (FlushClient+0x348) [0x76d228]
     > (EE) 5: /opt/thinlinc/libexec/Xvnc (WriteToClient+0x100) [0x76d460]
     > (EE) 6: /opt/thinlinc/libexec/Xvnc (ProcXIGetSelectedEvents+0x2a8) [0x54fd98]
     > (EE) 7: /opt/thinlinc/libexec/Xvnc (Dispatch+0x325) [0x71c925]
     > (EE) 8: /opt/thinlinc/libexec/Xvnc (dix_main+0x388) [0x720778]
     > (EE) 9: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xf3) [0x7f73416f5083]
     > (EE) 10: /opt/thinlinc/libexec/Xvnc (0x400000+0xc2fa0) [0x4c2fa0]
     > (EE)
     > (EE) Segmentation fault at address 0x17b40b60
     > (EE)
     >
     > I'm not sure if I can easily get a Xvnc core dump, though.

He also reports the same issue with Debian/sparc64, which
we think means that it seems not to be an OS-specific issue:

     > For comparison's sake, I tried the same with a Debian/sparc64 LDom I
     > have around for some LLVM and GCC work.  I installed emacs 29.2 there,
     > too (from packages this time) and was 'rewarded' with exactly the same
     > Xvnc SEGV as before.  So there's nothing Solaris specific in here, it
     > seems.

I'd appreciate it if someone who knows this code could have
a look. I'm happy to try patches or experiments to help narrow
the issue down further.

Thanks.

- Ali

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]

ali_gnu2@emvision.com writes:

> Hello,
>
>    I maintain the the GNU emacs delivered with the
> Solaris OS:
>
>     https://github.com/oracle/solaris-userland/tree/master/components/emacs
>
> We're still at version 28.2. It's getting long in the
> tooth, so I recently tried to move to 29.2. There were no
> issues on x86, but on sparc, I see display problems with
> both the gtk (emacs-gtk) and lucid (emacs-x) versions that
> prevent it from running.
>
> I double checked version 28.2, which we are currently
> delivering, and it has no problem. Then, I built 29.1,
> and it shows the same issues as 29.2. It seems that
> something was introduced early in the 29 series.
>
> With the GTK version, I see 3 different failures on repeated
> attempts:
>
> 1)
>
>     % emacs-gtk
>     Connection lost to X server 'localhost:10.0'
>     When compiled with GTK, Emacs cannot recover from X disconnects.
>     This is a GTK bug: https://gitlab.gnome.org/GNOME/gtk/issues/221
>     For details, see etc/PROBLEMS.
>     Fatal error 6: Aborted
>     Backtrace:
>     /usr/bin/emacs-gtk'emacs_backtrace+0x50 [0x1ffe749825f2ac]
>     /usr/bin/emacs-gtk'terminate_due_to_signal+0xb4 [0x1ffe749822f804]
>     /usr/bin/emacs-gtk'emacs_abort+0x8 [0x1ffe74982609c4]
>     /usr/bin/emacs-gtk'x_connection_closed+0x3cc [0x1ffe74981efd54]
>     /usr/bin/emacs-gtk'x_io_error_quitter+0x3c [0x1ffe74981f00f0]
>     /usr/lib/sparcv9/libX11.so.4.0.0'_XIOError+0x74 [0x1ffe74904f8034]
>     /usr/lib/sparcv9/libX11.so.4.0.0'_XReply+0x360 [0x1ffe74904f3bf0]
>     /usr/lib/sparcv9/libXi.so.5.0.0'XIGetSelectedEvents+0x84 [0x1ffe748ed17044]
>     /usr/bin/emacs-gtk'Fx_create_frame+0x17b4 [0x1ffe74982172fc]
>     /usr/bin/emacs-gtk'funcall_subr+0x120 [0x1ffe74982e6f58]
>     /usr/bin/emacs-gtk'exec_byte_code+0x52c [0x1ffe74983470e0]
>     /usr/bin/emacs-gtk'Ffuncall+0x108 [0x1ffe74982e37d4]
>     /usr/bin/emacs-gtk'Fapply+0x378 [0x1ffe74982e3c98]
>     /usr/bin/emacs-gtk'funcall_subr+0xa8 [0x1ffe74982e6ee0]
>     /usr/bin/emacs-gtk'exec_byte_code+0x52c [0x1ffe74983470e0]
>     /usr/bin/emacs-gtk'apply_lambda+0xd4 [0x1ffe74982ea734]
>     /usr/bin/emacs-gtk'eval_sub+0x630 [0x1ffe74982e88c0]
>     /usr/bin/emacs-gtk'Feval+0x60 [0x1ffe74982ebb2c]
>     /usr/bin/emacs-gtk'internal_condition_case+0x78 [0x1ffe74982e1bbc]
>     /usr/bin/emacs-gtk'top_level_1+0x40 [0x1ffe7498233bd0]
>     /usr/bin/emacs-gtk'internal_catch+0x40 [0x1ffe74982e1ae8]
>     /usr/bin/emacs-gtk'command_loop+0xd8 [0x1ffe749823241c]
>     /usr/bin/emacs-gtk'recursive_edit_1+0xb8 [0x1ffe7498237d4c]
>     /usr/bin/emacs-gtk'Frecursive_edit+0x124 [0x1ffe7498238274]
>     /usr/bin/emacs-gtk'main+0x1f28 [0x1ffe7498231770]
>     /usr/bin/emacs-gtk'_start+0x64 [0x1ffe74980c5c04]
>     Abort (core dumped)
>
>     Note that I don't believe that X disconnects are involved.
>     This happened immediately at startup.
>
> 2)
>
>     % emacs-gtk
>     [xcb] Unknown sequence number while processing queue
>     [xcb] You called XInitThreads, this is not your fault
>     [xcb] Aborting, sorry about that.
>     Assertion failed: !xcb_xlib_threads_sequence_lost, file /builds/ulhg/mrcarson-trunk_166/components/x11/lib/libX11/libX11-1.8.7/src/xcb_io.c, line 278, function poll_for_event
>     Fatal error 6: Aborted
>     Backtrace:
>     /usr/bin/emacs-gtk'emacs_backtrace+0x50 [0x1fffec39a5f2ac]
>     /usr/bin/emacs-gtk'terminate_due_to_signal+0xb4 [0x1fffec39a2f804]
>     /usr/bin/emacs-gtk'handle_fatal_signal+0x8 [0x1fffec39a609b0]
>     /usr/bin/emacs-gtk'deliver_fatal_thread_signal+0x98 [0x1fffec39a5d4b8]
>     /lib/sparcv9/libc.so.1'__sighndlr+0xc [0x1fffec392c6410]
>     /lib/sparcv9/libc.so.1'call_user_handler+0x400 [0x1fffec392b8cb8]
>     /lib/sparcv9/libc.so.1'sigacthandler+0xd0 [0x1fffec392b90a8]
>     /lib/sparcv9/libc.so.1'__lwp_sigqueue+0x8 [0x1fffec392cb528]
>     /lib/sparcv9/libc.so.1'abort+0xb4 [0x1fffec391e5154]
>     /lib/sparcv9/libc.so.1'_assert_c99+0x64 [0x1fffec391e5ffc]
>     /usr/lib/sparcv9/libX11.so.4.0.0'poll_for_event+0x1fc [0x1fffec31cf2a8c]
>     /usr/lib/sparcv9/libX11.so.4.0.0'poll_for_response+0x2c [0x1fffec31cf2b2c]
>     /usr/lib/sparcv9/libX11.so.4.0.0'_XEventsQueued+0x7c [0x1fffec31cf2e8c]
>     /usr/lib/sparcv9/libX11.so.4.0.0'XFlush+0x1c [0x1fffec31cba45c]
>     /usr/bin/emacs-gtk'x_set_icon_type+0x70 [0x1fffec39a0c640]
>     /usr/bin/emacs-gtk'gui_set_frame_parameters_1+0x1800 [0x1fffec398e0028]
>     /usr/bin/emacs-gtk'gui_default_parameter+0x58 [0x1fffec398e55e8]
>     /usr/bin/emacs-gtk'Fx_create_frame+0xf20 [0x1fffec39a16a68]
>     /usr/bin/emacs-gtk'funcall_subr+0x120 [0x1fffec39ae6f58]
>     /usr/bin/emacs-gtk'exec_byte_code+0x52c [0x1fffec39b470e0]
>     /usr/bin/emacs-gtk'Ffuncall+0x108 [0x1fffec39ae37d4]
>     /usr/bin/emacs-gtk'Fapply+0x378 [0x1fffec39ae3c98]
>     /usr/bin/emacs-gtk'funcall_subr+0xa8 [0x1fffec39ae6ee0]
>     /usr/bin/emacs-gtk'exec_byte_code+0x52c [0x1fffec39b470e0]
>     /usr/bin/emacs-gtk'apply_lambda+0xd4 [0x1fffec39aea734]
>     /usr/bin/emacs-gtk'eval_sub+0x630 [0x1fffec39ae88c0]
>     /usr/bin/emacs-gtk'Feval+0x60 [0x1fffec39aebb2c]
>     /usr/bin/emacs-gtk'internal_condition_case+0x78 [0x1fffec39ae1bbc]
>     /usr/bin/emacs-gtk'top_level_1+0x40 [0x1fffec39a33bd0]
>     /usr/bin/emacs-gtk'internal_catch+0x40 [0x1fffec39ae1ae8]
>     /usr/bin/emacs-gtk'command_loop+0xd8 [0x1fffec39a3241c]
>     /usr/bin/emacs-gtk'recursive_edit_1+0xb8 [0x1fffec39a37d4c]
>     /usr/bin/emacs-gtk'Frecursive_edit+0x124 [0x1fffec39a38274]
>     /usr/bin/emacs-gtk'main+0x1f28 [0x1fffec39a31770]
>     /usr/bin/emacs-gtk'_start+0x64 [0x1fffec398c5c04]
>     Abort (core dumped)
>
> 3)
>
>     Sometimes, this clobbers the state of my video card, leaving
>     me with a black screen with a large white square in the upper
>     left corner. When this happens, I log in remotely, and using
>     ps, it appears that my desktop is still running, so the X server
>     is unaware that the video hardware has been whacked. I can only
>     assume that a bad request is not being caught by the X11 server,
>     which is likely a second bug.
>
> With the Lucid version, I normally get this result, after
> a long pause:
>
>     % emacs-x
>
>     Connection lost to X server 'localhost:10.0'
>
> The fact that both the plain X11, and GTK, versions, have
> problems seems to point at some generic non-toolkit specific
> X code. Perhaps this is an endian issue (x86 works fine), or
> maybe there's some uninitialized data involved.
>
> I asked Rainer Orth, who I work with on Solaris gcc issues, and
> who I know is also an emacs user, and he was able to confirm the
> same issues, using a different X server:
>
>     >> Given that I'm still on 27.1.90/28.2 myself, I didn't.  On the sparc
>     >> side, I primarily use emacs to run gdb, which I haven't done in a
>     >> while.  I can give it a whirl, though.
>     >
>     > here's what I found: I configured emacs with
>     >
>     > configure \
>     > 	'CFLAGS=-g3 -O2 -m64' \
>     >         --prefix=/vol/gnu \
>     >         --with-gif=ifavailable
>     >         PKG_CONFIG_PATH=/usr/lib/64/pkgconfig:/usr/lib/64/pkgconfig:/usr/share/pkgconfig
>     >
>     > and built it with the bundled gcc 13.2.0.  Started just fine with emacs
>     > -nw (to confirm the basics), but then I started it remotely from my
>     > ThinLinc session at work (the thin client we use): that resulted in an
>     > immediate SEGV of Xvnc and termination of the session.  I'm glad I
>     > didn't try this from my session at home 😉
>     >
>     > The Xvnc backtrace is like this:
>     >
>     > (EE)
>     > (EE) Backtrace:
>     > (EE) 0: /opt/thinlinc/libexec/Xvnc (xorg_backtrace+0x41) [0x76a2f1]
>     > (EE) 1: /opt/thinlinc/libexec/Xvnc (0x400000+0x36d909) [0x76d909]
>     > (EE) 2: /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f7341b61000+0x14420)
>     > [0x7f7341b75420]
>     > (EE) 3: /lib/x86_64-linux-gnu/libc.so.6 (0x7f73416d1000+0x18bb38)
>     > [0x7f734185cb38]
>     > (EE) 4: /opt/thinlinc/libexec/Xvnc (FlushClient+0x348) [0x76d228]
>     > (EE) 5: /opt/thinlinc/libexec/Xvnc (WriteToClient+0x100) [0x76d460]
>     > (EE) 6: /opt/thinlinc/libexec/Xvnc (ProcXIGetSelectedEvents+0x2a8) [0x54fd98]
>     > (EE) 7: /opt/thinlinc/libexec/Xvnc (Dispatch+0x325) [0x71c925]
>     > (EE) 8: /opt/thinlinc/libexec/Xvnc (dix_main+0x388) [0x720778]
>     > (EE) 9: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xf3) [0x7f73416f5083]
>     > (EE) 10: /opt/thinlinc/libexec/Xvnc (0x400000+0xc2fa0) [0x4c2fa0]
>     > (EE)
>     > (EE) Segmentation fault at address 0x17b40b60
>     > (EE)
>     >
>     > I'm not sure if I can easily get a Xvnc core dump, though.
>
> He also reports the same issue with Debian/sparc64, which
> we think means that it seems not to be an OS-specific issue:
>
>     > For comparison's sake, I tried the same with a Debian/sparc64 LDom I
>     > have around for some LLVM and GCC work.  I installed emacs 29.2 there,
>     > too (from packages this time) and was 'rewarded' with exactly the same
>     > Xvnc SEGV as before.  So there's nothing Solaris specific in here, it
>     > seems.
>
> I'd appreciate it if someone who knows this code could have
> a look. I'm happy to try patches or experiments to help narrow
> the issue down further.

Emacs works fine on sparc64-sun-solaris2.10, but the difference is that
the X libraries and servers installed there are ancient and predate the
introduction of generic events or XInput 2.  The backtrace Rainer
produced demonstrates that the client-side abort is consequent on the X
server crashing as it attempts to respond to an XIGetSelectedEvents
request, which is _always_ a bug in the X server, whatever the
circumstances, and so I suggest redirecting your attention to X.Org, and
building `--without-xinput2' in the meantime.

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

[ali_gnu2]

On 3/12/24 6:34 PM, Po Lu wrote:
> Emacs works fine on sparc64-sun-solaris2.10, but the difference is that
> the X libraries and servers installed there are ancient and predate the
> introduction of generic events or XInput 2.  The backtrace Rainer
> produced demonstrates that the client-side abort is consequent on the X
> server crashing as it attempts to respond to an XIGetSelectedEvents
> request, which is _always_ a bug in the X server, whatever the
> circumstances, and so I suggest redirecting your attention to X.Org, and
> building `--without-xinput2' in the meantime.

    Thank you, this is very helpful. I guess I'm not too surprised
that it works on Solaris 10. Your support of a 20 year old OS is
admirable.

I tried --without-xinput2 with the GTK version, and it does
indeed skirt the problem. I can now reliably run it without
crashing.

Since this all worked with 28.2, I guess that Emacs
started using XInput 2 features in the 29.1 branch?

Unfortunately, with the Lucid version, while --without-xinput2
seems to get past the failure I reported, there's now a different
failure:

     % src/emacs
     X protocol error: BadDrawable (invalid Pixmap or Window parameter) on protocol request 134
     Serial no: 1318

- Ali

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]

ali_gnu2@emvision.com writes:

>    Thank you, this is very helpful. I guess I'm not too surprised
> that it works on Solaris 10. Your support of a 20 year old OS is
> admirable.
>
> I tried --without-xinput2 with the GTK version, and it does
> indeed skirt the problem. I can now reliably run it without
> crashing.
>
> Since this all worked with 28.2, I guess that Emacs
> started using XInput 2 features in the 29.1 branch?

Yes.

> Unfortunately, with the Lucid version, while --without-xinput2
> seems to get past the failure I reported, there's now a different
> failure:
>
>     % src/emacs
>     X protocol error: BadDrawable (invalid Pixmap or Window parameter) on protocol request 134
>     Serial no: 1318

Please run Emacs under gdb (or some other suitable debugger, e.g. dbx)
with the command-line options:

  -q -xrm 'Emacs.synchronous: True'

exactly as written above, break on xterm.c:x_error_quitter, and reply
with the backtrace generated after this breakpoint is hit.

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

[Ali Bahrami]

On 3/13/24 6:17 PM, Po Lu wrote:
> Please run Emacs under gdb (or some other suitable debugger, e.g. dbx)
> with the command-line options:
> 
>    -q -xrm 'Emacs.synchronous: True'
> 
> exactly as written above, break on xterm.c:x_error_quitter, and reply
> with the backtrace generated after this breakpoint is hit.

The gdb output follows. Thanks.

- Ali

-----
% gdb src/emacs
GNU gdb (GDB) 13.1
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "sparc-sun-solaris2.11".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
     <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from src/emacs...
(gdb) break xterm.c:x_error_quitter
warning: could not convert 'x_error_quitter' from the host encoding (ISO-8859-1) to UTF-32.
This normally should not happen, please file a bug report.
Breakpoint 1 at 0x1001acebc: file xterm.c, line 26129.
(gdb) run -q -xrm 'Emacs.synchronous: True'
alib-us:~ alib$ cat Desktop/emacs-x.dbg
% gdb src/emacs
GNU gdb (GDB) 13.1
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "sparc-sun-solaris2.11".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
     <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from src/emacs...
(gdb) break xterm.c:x_error_quitter
warning: could not convert 'x_error_quitter' from the host encoding (ISO-8859-1) to UTF-32.
This normally should not happen, please file a bug report.
Breakpoint 1 at 0x1001acebc: file xterm.c, line 26129.
(gdb) run -q -xrm 'Emacs.synchronous: True'
Starting program: /builds2/alib/emacs292/emacs-29.2/src/emacs -q -xrm 'Emacs.synchronous: True'
[Thread debugging using libthread_db enabled]
[New Thread 1 (LWP 1)]
[New LWP    2        ]
[New Thread 2 (LWP 2)]
[Switching to Thread 1 (LWP 1)]

Thread 2 hit Breakpoint 1, x_error_quitter (display=0x101534ab0,
     event=0xffffffff7fffdc70) at xterm.c:26129
26129   {
(gdb) where
#0  x_error_quitter (display=0x101534ab0, event=0xffffffff7fffdc70)
     at xterm.c:26129
#1  0x00000001001acff0 in x_error_handler
     (display=<optimized out>, event=0xffffffff7fffdc70) at xterm.c:26117
#2  0x00007ffff09f7ec4 in _XError () at /usr/lib/64/libX11.so.4
#3  0x00007ffff09f27fc in handle_error () at /usr/lib/64/libX11.so.4
#4  0x00007ffff09f3a60 in _XReply () at /usr/lib/64/libX11.so.4
#5  0x00007ffff09e8230 in XSync () at /usr/lib/64/libX11.so.4
#6  0x00007ffff09e82e0 in _XSyncFunction () at /usr/lib/64/libX11.so.4
#7  0x00007ffff0211018 in XSyncCreateFence () at /usr/lib/64/libXext.so.0
#8  0x00000001001a4328 in x_sync_init_fences (f=0x1016fd3e8) at xterm.c:7064
#9  0x00000001001ceb20 in Fx_create_frame (parms=0x1015067d3) at xfns.c:5222
#10 0x0000000100281c40 in funcall_subr
     (subr=0x1008c16b0 <Sx_create_frame>, numargs=1, args=<optimized out>)
     at eval.c:3038
#11 0x00000001002d2cc8 in exec_byte_code
     (fun=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>) at /builds2/alib/emacs292/emacs-29.2/src/lisp.h:2211
#12 0x000000010027e0f4 in Ffuncall (nargs=2, args=0x1010efe78) at eval.c:2999
#13 0x000000010027e634 in Fapply (nargs=2, args=0x1010efe78) at eval.c:2627
#14 0x0000000100281bc8 in funcall_subr
     (subr=0x1008c89c0 <Sapply>, numargs=2, args=0x1010efe78) at eval.c:3063
#15 0x00000001002d2cc8 in exec_byte_code
     (fun=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>) at /builds2/alib/emacs292/emacs-29.2/src/lisp.h:2211
#16 0x0000000100283fbc in apply_lambda
     (fun=0xffffffff7ea0fa5d, args=<optimized out>, count=...) at eval.c:3107
#17 0x00000001002820d8 in eval_sub (form=<optimized out>) at eval.c:2592
#18 0x0000000100285260 in Feval
     (form=0xffffffff7eb9242b, lexical=<optimized out>) at eval.c:2365
#19 0x000000010027c4e0 in internal_condition_case
     (bfun=0x1001df06c <top_level_2>, handlers=0x90, hfun=0x1001e792c <cmd_error>) at eval.c:1474
#20 0x00000001001dfbbc in top_level_1 (ignore=<optimized out>)
     at keyboard.c:1150
#21 0x000000010027c414 in internal_catch
     (tag=0xf9c0, func=0x1001dfb74 <top_level_1>, arg=0x0) at eval.c:1197
#22 0x00000001001defdc in command_loop () at keyboard.c:1110
#23 0x00000001001e7328 in recursive_edit_1 () at keyboard.c:720
#24 0x00000001001e785c in Frecursive_edit () at keyboard.c:803
#25 0x00000001001ddd1c in main (argc=4, argv=<optimized out>) at emacs.c:2521

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]

Ali Bahrami <ali_gnu2@emvision.com> writes:

> On 3/13/24 6:17 PM, Po Lu wrote:
>> Please run Emacs under gdb (or some other suitable debugger, e.g. dbx)
>> with the command-line options:
>>    -q -xrm 'Emacs.synchronous: True'
>> exactly as written above, break on xterm.c:x_error_quitter, and
>> reply
>> with the backtrace generated after this breakpoint is hit.
>
> The gdb output follows. Thanks.

Thanks.  Does this resolve the problem?

diff --git a/src/xterm.c b/src/xterm.c
index c8a43785564..55aba5b8604 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),
+			FRAME_OUTER_WINDOW (f),
 			False);
   output->sync_fences[1]
     = XSyncCreateFence (FRAME_X_DISPLAY (f),
-			FRAME_X_WINDOW (f),
+			FRAME_OUTER_WINDOW (f),
 			False);
 
   XChangeProperty (FRAME_X_DISPLAY (f), FRAME_OUTER_WINDOW (f),

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

[Ali Bahrami]

On 3/14/24 12:16 AM, Po Lu wrote:
> Ali Bahrami <ali_gnu2@emvision.com> writes:
> 
>> On 3/13/24 6:17 PM, Po Lu wrote:
>>> Please run Emacs under gdb (or some other suitable debugger, e.g. dbx)
>>> with the command-line options:
>>>     -q -xrm 'Emacs.synchronous: True'
>>> exactly as written above, break on xterm.c:x_error_quitter, and
>>> reply
>>> with the backtrace generated after this breakpoint is hit.
>>
>> The gdb output follows. Thanks.
> 
> Thanks.  Does this resolve the problem?
> 
> diff --git a/src/xterm.c b/src/xterm.c
> index c8a43785564..55aba5b8604 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),
> +			FRAME_OUTER_WINDOW (f),
>   			False);
>     output->sync_fences[1]
>       = XSyncCreateFence (FRAME_X_DISPLAY (f),
> -			FRAME_X_WINDOW (f),
> +			FRAME_OUTER_WINDOW (f),
>   			False);
>   
>     XChangeProperty (FRAME_X_DISPLAY (f), FRAME_OUTER_WINDOW (f),


I'm afraid not. I get the same result as before:

     % src/emacs
     X protocol error: BadDrawable (invalid Pixmap or Window parameter) on protocol request 134
     Serial no: 1318

- Ali

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]

Ali Bahrami <ali_gnu2@emvision.com> writes:

> I'm afraid not. I get the same result as before:
>
>     % src/emacs
>     X protocol error: BadDrawable (invalid Pixmap or Window parameter) on protocol request 134
>     Serial no: 1318

Several additional lines should have been printed after the failing
request's serial number.  Would you please post the error message in
whole?

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

[Ali Bahrami]

On 3/14/24 8:46 PM, Po Lu wrote:
> Ali Bahrami <ali_gnu2@emvision.com> writes:
> 
>> I'm afraid not. I get the same result as before:
>>
>>      % src/emacs
>>      X protocol error: BadDrawable (invalid Pixmap or Window parameter) on protocol request 134
>>      Serial no: 1318
> 
> Several additional lines should have been printed after the failing
> request's serial number.  Would you please post the error message in
> whole?


That really is all the output.

I'm running it as 'src/emacs', out of the workspace
that I built with the patch applied, as well as configured
with --without-xinput2. Did I miss a step, or should I be
running it differently?

- Ali

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]

Ali Bahrami <ali@emvision.com> writes:

> I'm running it as 'src/emacs', out of the workspace
> that I built with the patch applied, as well as configured
> with --without-xinput2. Did I miss a step, or should I be
> running it differently?

Nevermind, the code to print this information wasn't installed in the
Emacs 29 branch, being written awfully close to the time of the release.

Please apply this patch and respond with the error message the patched
Emacs generates:

diff --git a/src/xterm.c b/src/xterm.c
index acb008475c7..9f6d5196720 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -26300,8 +26300,10 @@ x_error_handler (Display *display, XErrorEvent *event)
 static void NO_INLINE
 x_error_quitter (Display *display, XErrorEvent *event)
 {
-  char buf[256], buf1[400 + INT_STRLEN_BOUND (int)
-		      + INT_STRLEN_BOUND (unsigned long)];
+  char buf[256], buf1[800 + INT_STRLEN_BOUND (int)
+		      + INT_STRLEN_BOUND (unsigned long)
+		      + INT_STRLEN_BOUND (XID)
+		      + INT_STRLEN_BOUND (int)];
 
   /* Ignore BadName errors.  They can happen because of fonts
      or colors that are not defined.  */
@@ -26314,8 +26316,12 @@ x_error_quitter (Display *display, XErrorEvent *event)
 
   XGetErrorText (display, event->error_code, buf, sizeof (buf));
   sprintf (buf1, "X protocol error: %s on protocol request %d\n"
-	   "Serial no: %lu\n", buf, event->request_code,
-	   event->serial);
+	   "Serial no: %lu\n"
+	   "Failing resource ID (if any): 0x%lx\n"
+	   "Minor code: %d\n",
+	   "This is a bug!  Please report this to bug-gnu-emacs@gnu.org!\n"
+	   buf, event->request_code, event->serial, event->resourceid,
+	   event->minor_code);
   x_connection_closed (display, buf1, false);
 }

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

[Ali Bahrami]

On 3/15/24 12:42 AM, Po Lu wrote:
> Ali Bahrami <ali@emvision.com> writes:
> 
>> I'm running it as 'src/emacs', out of the workspace
>> that I built with the patch applied, as well as configured
>> with --without-xinput2. Did I miss a step, or should I be
>> running it differently?
> 
> Nevermind, the code to print this information wasn't installed in the
> Emacs 29 branch, being written awfully close to the time of the release.
> 
> Please apply this patch and respond with the error message the patched
> Emacs generates:
> 
> diff --git a/src/xterm.c b/src/xterm.c
> index acb008475c7..9f6d5196720 100644
> --- a/src/xterm.c
> +++ b/src/xterm.c
> @@ -26300,8 +26300,10 @@ x_error_handler (Display *display, XErrorEvent *event)
>   static void NO_INLINE
>   x_error_quitter (Display *display, XErrorEvent *event)
>   {
> -  char buf[256], buf1[400 + INT_STRLEN_BOUND (int)
> -		      + INT_STRLEN_BOUND (unsigned long)];
> +  char buf[256], buf1[800 + INT_STRLEN_BOUND (int)
> +		      + INT_STRLEN_BOUND (unsigned long)
> +		      + INT_STRLEN_BOUND (XID)
> +		      + INT_STRLEN_BOUND (int)];
>   
>     /* Ignore BadName errors.  They can happen because of fonts
>        or colors that are not defined.  */
> @@ -26314,8 +26316,12 @@ x_error_quitter (Display *display, XErrorEvent *event)
>   
>     XGetErrorText (display, event->error_code, buf, sizeof (buf));
>     sprintf (buf1, "X protocol error: %s on protocol request %d\n"
> -	   "Serial no: %lu\n", buf, event->request_code,
> -	   event->serial);
> +	   "Serial no: %lu\n"
> +	   "Failing resource ID (if any): 0x%lx\n"

> +	   "This is a bug!  Please report this to bug-gnu-emacs@gnu.org!\n"
> +	   buf, event->request_code, event->serial, event->resourceid,
> +	   event->minor_code);
>     x_connection_closed (display, buf1, false);
>   }



    This output is from emacs-x with both patches
applied:

     % src/emacs
     X protocol error: BadDrawable (invalid Pixmap or Window parameter) on protocol request 134
     Serial no: 1318
     Failing resource ID (if any): 0x5901a002
     Minor code: 14
     This is a bug!  Please report this to bug-gnu-emacs@gnu.org!

Note that I had to move the comma at the end of

     > +	   "Minor code: %d\n",

to the end of the following line. I only mention it in case
it's a sign that something else was intended.

Standing by for the next iteration. Thank you!

- Ali

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]

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

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

[Ali Bahrami]

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

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]

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,

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]

Po Lu <luangruo@yahoo.com> writes:

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

Scratch that,

diff --git a/src/xterm.c b/src/xterm.c
index c8a43785564..2358918ac5b 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);
 
   XChangeProperty (FRAME_X_DISPLAY (f), FRAME_OUTER_WINDOW (f),
 		   dpyinfo->Xatom_net_wm_sync_fences, XA_CARDINAL,

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

[Ali Bahrami]

On 3/16/24 12:28 AM, Po Lu wrote:
> Ali Bahrami <ali_gnu2@emvision.com> writes:
>> 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.

It's a good question, and I don't know the answer.
However, it's worth noting that it's been 20 years
since sparc machines came in desktop form, with a
display, so the number of people running X11 clients
on them likely isn't large. I myself usually use the
plain tty version in those contexts.

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

 > Scratch that,
 >
 > diff --git a/src/xterm.c b/src/xterm.c
 > index c8a43785564..2358918ac5b 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);
 >
 >     XChangeProperty (FRAME_X_DISPLAY (f), FRAME_OUTER_WINDOW (f),
 >   		   dpyinfo->Xatom_net_wm_sync_fences, XA_CARDINAL,

The x_ignore_errors_for_next_request() in 29.2 only
takes the dpyinfo argument. I dropped the second argument
from this patch, applied it, and it works. We could go with this,
rather than my

     #ifdef __sparc
	return
     #endif

construct. It probably amounts to the same thing,
except that should a fixed XSyncCreateFence() come
along, this version would start using it.

Thanks!

- Ali

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

[Eli Zaretskii]

> Cc: 69762@debbugs.gnu.org
> Date: Wed, 13 Mar 2024 11:02:00 -0600
> From: ali_gnu2@emvision.com
> 
> On 3/12/24 6:34 PM, Po Lu wrote:
> > Emacs works fine on sparc64-sun-solaris2.10, but the difference is that
> > the X libraries and servers installed there are ancient and predate the
> > introduction of generic events or XInput 2.  The backtrace Rainer
> > produced demonstrates that the client-side abort is consequent on the X
> > server crashing as it attempts to respond to an XIGetSelectedEvents
> > request, which is _always_ a bug in the X server, whatever the
> > circumstances, and so I suggest redirecting your attention to X.Org, and
> > building `--without-xinput2' in the meantime.
> 
>     Thank you, this is very helpful. I guess I'm not too surprised
> that it works on Solaris 10. Your support of a 20 year old OS is
> admirable.
> 
> I tried --without-xinput2 with the GTK version, and it does
> indeed skirt the problem. I can now reliably run it without
> crashing.

Po Lu, please document in PROBLEMS that XInput2 has bugs on Solaris
(probably only reecent versions?)

Thanks.

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]

Eli Zaretskii <eliz@gnu.org> writes:

> Po Lu, please document in PROBLEMS that XInput2 has bugs on Solaris
> (probably only reecent versions?)

I actually plan to install a workaround for the non-toolkit builds once
we arrive at a solution for the other bug under discussion.  Thanks.

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

[ali_gnu2]

On 3/16/24 5:14 AM, Eli Zaretskii wrote:
>> I tried --without-xinput2 with the GTK version, and it does
>> indeed skirt the problem. I can now reliably run it without
>> crashing.
> Po Lu, please document in PROBLEMS that XInput2 has bugs on Solaris
> (probably only reecent versions?)


    We don't see this issue on Solaris/X86, and we did see
it on Debian/sparc. We won't really know until the issue is
root caused, but I'd say "on sparc" is probably more accurate
than "on Solaris".

Regarding recent versions, it's not known at this time.
We only know that it works on Solaris 10, a 20 year old
system that lacks XInput2, and does not work on the latest
Solaris. Although it's possible that this worked on slightly
older versions of Solaris/sparc, I haven't tested. My unverified
hunch is that it's more likely that XInput2 never worked on
sparc, and no one noticed until emacs 29 came along. If so,
then this bug could go back a decade or so (google tells me
XInput2 was proposed in 2012).

- Ali

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]

ali_gnu2@emvision.com writes:

> Regarding recent versions, it's not known at this time.
> We only know that it works on Solaris 10, a 20 year old
> system that lacks XInput2, and does not work on the latest
> Solaris. Although it's possible that this worked on slightly
> older versions of Solaris/sparc, I haven't tested. My unverified
> hunch is that it's more likely that XInput2 never worked on
> sparc, and no one noticed until emacs 29 came along. If so,
> then this bug could go back a decade or so (google tells me
> XInput2 was proposed in 2012).

Whatever the conditions for the X server crash, please report it (or ask
Rainier to do so) to the X.Org developers.  Between the recent deletion
of support for byte-swapping and its developers transition to only
assembling Xwayland releases, there is very little love remaining in
that organization for the rank-and-file of X users, and every reminder
of our existence counts towards restoring some of that lost dedication.
If you catch my drift.

Thanks.

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

[Alan Coopersmith]

Ali asked me to look into this bug as one of the X11 maintainers for
Solaris, but I also am one of the upstream maintainers for X.Org.

On 3/17/24 04:54, Po Lu wrote:
> Whatever the conditions for the X server crash, please report it (or ask
> Rainier to do so) to the X.Org developers.  Between the recent deletion
> of support for byte-swapping and its developers transition to only
> assembling Xwayland releases, there is very little love remaining in
> that organization for the rank-and-file of X users, and every reminder
> of our existence counts towards restoring some of that lost dedication.

There's still some of us working to maintain X11 for X11 users (mostly
because Wayland isn't an option for our kernel).  Also note that byte
swapping was *not* deleted, just disabled by default and can be easily
re-enabled.   Which is important here, because the bugs Ali & Rainer
found are not SPARC-specific, but caused by them running emacs on a
SPARC and displaying it onto an x86 desktop, thus invoking the byte
swapping code where both the Xsync & Xinput2 bugs lie.

I've merged a fix upstream for the Xsync bug already, as it was quite
simple: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1437/

The Xinput2 one is a little more involved and I'm working on getting it
fixed upstream now.

-- 
         -Alan Coopersmith-                 alan.coopersmith@oracle.com
          Oracle Solaris Engineering - https://blogs.oracle.com/solaris

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

[Alan Coopersmith via Bug reports for GNU Emacs, the Swiss army knife of text editors]

On 3/23/24 10:00, Alan Coopersmith wrote:
> The Xinput2 one is a little more involved and I'm working on getting it
> fixed upstream now.

That fix is merged upstream as well now:
https://gitlab.freedesktop.org/xorg/xserver/-/commit/96798fc1967491c80a4d0c8d9e0a80586cb2152b

-- 
         -Alan Coopersmith-                 alan.coopersmith@oracle.com
          Oracle Solaris Engineering - https://blogs.oracle.com/solaris

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

[Eli Zaretskii]

> Date: Wed, 3 Apr 2024 10:48:16 -0700
> From: Alan Coopersmith <alan.coopersmith@oracle.com>
> Cc: 69762@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>
> 
> On 3/23/24 10:00, Alan Coopersmith wrote:
> > The Xinput2 one is a little more involved and I'm working on getting it
> > fixed upstream now.
> 
> That fix is merged upstream as well now:
> https://gitlab.freedesktop.org/xorg/xserver/-/commit/96798fc1967491c80a4d0c8d9e0a80586cb2152b

Thanks.

Po Lu, should we now close this bug?

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]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Wed, 3 Apr 2024 10:48:16 -0700
>> From: Alan Coopersmith <alan.coopersmith@oracle.com>
>> Cc: 69762@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>
>> 
>> On 3/23/24 10:00, Alan Coopersmith wrote:
>> > The Xinput2 one is a little more involved and I'm working on getting it
>> > fixed upstream now.
>> 
>> That fix is merged upstream as well now:
>> https://gitlab.freedesktop.org/xorg/xserver/-/commit/96798fc1967491c80a4d0c8d9e0a80586cb2152b
>
> Thanks.
>
> Po Lu, should we now close this bug?

Yes.  Thanks, Alan and all.

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

[ali_gnu2]

On 4/6/24 5:07 AM, Po Lu wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
> 
>>> Date: Wed, 3 Apr 2024 10:48:16 -0700
>>> From: Alan Coopersmith <alan.coopersmith@oracle.com>
>>> Cc: 69762@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>
>>>
>>> On 3/23/24 10:00, Alan Coopersmith wrote:
>>>> The Xinput2 one is a little more involved and I'm working on getting it
>>>> fixed upstream now.
>>>
>>> That fix is merged upstream as well now:
>>> https://gitlab.freedesktop.org/xorg/xserver/-/commit/96798fc1967491c80a4d0c8d9e0a80586cb2152b
>>
>> Thanks.
>>
>> Po Lu, should we now close this bug?
> 
> Yes.  Thanks, Alan and all.

    It also means that the extra error handling
you put together as a workaround can probably
be omitted. Had that workaround been in place
earlier, we would never have found and gotten
these issues fixed.

Thanks again for all your time in debugging this.

- Ali

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]

ali_gnu2@emvision.com writes:

>    It also means that the extra error handling
> you put together as a workaround can probably
> be omitted. Had that workaround been in place
> earlier, we would never have found and gotten
> these issues fixed.

Thanks, but our policy is to support all X servers users might plausibly
encounter, so the workaround must remain, all the more so with such a
widely-distributed X server.