Re: server.el test failures

[Eli Zaretskii <eliz@gnu.org>]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: jporterbugs@gmail.com,  eggert@cs.ucla.edu,  emacs-devel@gnu.org
> Date: Tue, 28 Feb 2023 08:42:56 +0100
> 
>     Eli>   (gdb) handle SIGIO stop print
> 
>     Eli> and then run the test in batch mode again.
> 
> That gets me the same backtrace:
> 
> (gdb) set args --module-assertions --no-init-file --no-site-file --no-site-lisp -L ":."  \
>   -l ert  -l lisp/server-tests.el \
>   --batch --eval '(ert-run-tests-batch-and-exit (quote (not (or (tag :unstable) (tag :nativecomp)))))' 
> (gdb) handle SIGIO stop print
> Signal        Stop      Print   Pass to program Description
> SIGIO         Yes       Yes     Yes             I/O possible
> (gdb) r
> Starting program: /home/rpluim/repos/emacs/src/emacs --module-assertions --no-init-file --no-site-file --no-site-lisp -L ":."  \
>   -l ert  -l lisp/server-tests.el \
>   --batch --eval '(ert-run-tests-batch-and-exit (quote (not (or (tag :unstable) (tag :nativecomp)))))' 
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> [New Thread 0x7ffff129d700 (LWP 26168)]
> Running 1 tests (2023-02-28 08:39:54+0100, selector `(not (or (tag :unstable) (tag :nativecomp)))')
> [Detaching after vfork from child process 26169]
> [New Thread 0x7fffebfff700 (LWP 26170)]
> [New Thread 0x7fffeb66e700 (LWP 26171)]
> 
> Thread 1 "emacs" received signal SIGIO, I/O possible.
> 0x00007ffff530fd2f in __GI___poll (fds=0x7fffffffa698, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
> 29      ../sysdeps/unix/sysv/linux/poll.c: No such file or directory.
> (gdb) bt
> #0  0x00007ffff530fd2f in __GI___poll (fds=0x7fffffffa698, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
> #1  0x00007ffff6d92d02 in  () at /lib/x86_64-linux-gnu/libxcb.so.1
> #2  0x00007ffff6d94d7f in  () at /lib/x86_64-linux-gnu/libxcb.so.1
> #3  0x00007ffff6d94e91 in xcb_wait_for_reply () at /lib/x86_64-linux-gnu/libxcb.so.1
> #4  0x00005555556a629b in x_term_init
>     (display_name=display_name@entry=XIL(0x5555560152d4), xrm_option=xrm_option@entry=0x0, resource_name=0x555556010260 "emacs") at xterm.c:30964
> #5  0x00005555556a96c7 in Fx_open_connection (display=XIL(0x5555560152d4), xrm_string=<optimized out>, must_succeed=XIL(0)) at xfns.c:7548

Why does make-frame create a GUI X frame in a batch session?  (I've
seen that in your previous backtrace, but thought it was because you
ran that test in an interactive session.)  Is that because emacsclient
and/or server insist on that, or because some snafu inside make-frame,
or something else?  Can you figure that out?  I looked at the code,
but didn't see anything obvious.

I don't think we should create GUI frames in batch, since the SIGIO
handler is not set, and we generally aren't prepared for receiving
it.  We should create a TTY frame instead, or maybe no frame at all.

Thanks.