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