server.el test failures (was: Re: bug#9800: Incomplete truncated file buffers from the /proc filesystem)

server.el test failures (was: Re: bug#9800: Incomplete truncated file buffers from the /proc filesystem)

[Jim Porter]

On 2/13/2023 12:47 PM, Paul Eggert wrote:
> PS. I was surprised to see that Emacs master currently has several test 
> case failures on GNU/Linux (specifically the latest Fedora and Ubuntu 
> releases). I hope these are known and that people are working on them.
> 
> 1 files did not finish:
>    lisp/server-tests.log

How did you run these tests? I don't see failures for this on EMBA, nor 
when running it manually on GNU/Linux (latest Mint) via "make -C test 
server-tests".

These tests are somewhat brittle since they spawn emacsclient processes 
to verify that the client can communicate with an Emacs server. The 
tests make some assumptions about how they'll be run, so probably one of 
those assumptions doesn't hold.

I thought we'd worked out all the issues with the tests, but apparently 
not...

Re: server.el test failures (was: Re: bug#9800: Incomplete truncated file buffers from the /proc filesystem)

[Paul Eggert]

On 2/13/23 13:55, Jim Porter wrote:
> On 2/13/2023 12:47 PM, Paul Eggert wrote:
>> PS. I was surprised to see that Emacs master currently has several 
>> test case failures on GNU/Linux (specifically the latest Fedora and 
>> Ubuntu releases). I hope these are known and that people are working 
>> on them.
>>
>> 1 files did not finish:
>>    lisp/server-tests.log
> 
> How did you run these tests?

'make -j5 check' on Fedora, 'make -j12 check' on Ubuntu.

Re: server.el test failures (was: Re: bug#9800: Incomplete truncated file buffers from the /proc filesystem)

[Jim Porter]

On 2/13/2023 6:47 PM, Paul Eggert wrote:
> On 2/13/23 13:55, Jim Porter wrote:
>> On 2/13/2023 12:47 PM, Paul Eggert wrote:
>>> 1 files did not finish:
>>>    lisp/server-tests.log
>>
>> How did you run these tests?
> 
> 'make -j5 check' on Fedora, 'make -j12 check' on Ubuntu.

Interesting. Running "./configure && make -j4 && make -j4 check" on both 
Emacs master and the 29 branch shows these tests passing for me.

Re: server.el test failures (was: Re: bug#9800: Incomplete truncated file buffers from the /proc filesystem)

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 449 bytes --]

On 2023-02-14 23:06, Jim Porter wrote:
> Interesting. Running "./configure && make -j4 && make -j4 check" on both 
> Emacs master and the 29 branch shows these tests passing for me.

I tried running it again on Ubuntu, several times, and this time 
server-tests.el succeeded. As you say, it may be a timing-related bug.

I still see other failures related to coding systems and the locale and 
reported them as Bug#61534.

https://bugs.gnu.org/61534

[-- Attachment #2: make-check-log.txt.gz --]
[-- Type: application/gzip, Size: 36911 bytes --]

Re: server.el test failures (was: Re: bug#9800: Incomplete truncated file buffers from the /proc filesystem)

[Paul Eggert]

On 2/15/23 10:20, Paul Eggert wrote:
> On 2023-02-14 23:06, Jim Porter wrote:
>> Interesting. Running "./configure && make -j4 && make -j4 check" on 
>> both Emacs master and the 29 branch shows these tests passing for me.
> 
> I tried running it again on Ubuntu, several times, and this time 
> server-tests.el succeeded. As you say, it may be a timing-related bug.

I tried running it on Fedora 37 x86-64 on a slow machine (AMD Phenom II 
X4 910e) and reproduced the timing bug. The output of 'make check' 
contained:

     GEN      lisp/server-tests.log
   Running 7 tests (2023-02-23 09:45:51-0800, selector `(not (or (tag 
:expensive-test) (tag :unstable) (tag :nativecomp)))')
   make[3]: *** [Makefile:174: lisp/server-tests.log] Error 157

I guess "Error 157" means signal 29 (157 - 128), which is SIGIO on this 
platform.

This was with Emacs master (commit 
6411a9af03a4eb1a82db47a9642b11ba7edaaaf0).

Re: server.el test failures (was: Re: bug#9800: Incomplete truncated file buffers from the /proc filesystem)

[Jim Porter]

On 2/23/2023 3:42 PM, Paul Eggert wrote:
> On 2/15/23 10:20, Paul Eggert wrote:
>> On 2023-02-14 23:06, Jim Porter wrote:
>>> Interesting. Running "./configure && make -j4 && make -j4 check" on 
>>> both Emacs master and the 29 branch shows these tests passing for me.
>>
>> I tried running it again on Ubuntu, several times, and this time 
>> server-tests.el succeeded. As you say, it may be a timing-related bug.
> 
> I tried running it on Fedora 37 x86-64 on a slow machine (AMD Phenom II 
> X4 910e) and reproduced the timing bug. The output of 'make check' 
> contained:
> 
>      GEN      lisp/server-tests.log
>    Running 7 tests (2023-02-23 09:45:51-0800, selector `(not (or (tag 
> :expensive-test) (tag :unstable) (tag :nativecomp)))')
>    make[3]: *** [Makefile:174: lisp/server-tests.log] Error 157
> 
> I guess "Error 157" means signal 29 (157 - 128), which is SIGIO on this 
> platform.
> 
> This was with Emacs master (commit 
> 6411a9af03a4eb1a82db47a9642b11ba7edaaaf0).

Since the last message I posted, I'm now also seeing this test fail, 
though I get a segfault instead. I bisected this to commit 
a555abc56d5270cebe94f904189526d7ac433a94 ("Fix order of faces in 
'face-list'").

I'm pretty surprised by this, since that patch is *very* simple, but I 
can reliably segfault with it, and never segfault without it. I'll keep 
digging to see what's going on here.

Re: server.el test failures (was: Re: bug#9800: Incomplete truncated file buffers from the /proc filesystem)

[Jim Porter]

[-- Attachment #1: Type: text/plain, Size: 806 bytes --]

On 2/23/2023 4:50 PM, Jim Porter wrote:
> Since the last message I posted, I'm now also seeing this test fail, 
> though I get a segfault instead. I bisected this to commit 
> a555abc56d5270cebe94f904189526d7ac433a94 ("Fix order of faces in 
> 'face-list'").
> 
> I'm pretty surprised by this, since that patch is *very* simple, but I 
> can reliably segfault with it, and never segfault without it. I'll keep 
> digging to see what's going on here.

The segfault is in FACE_FROM_ID_OR_NULL, called from 
Finternal_merge_in_global_face. It happens because the face_cache is 
null during these tests (since Emacs is noninteractive).

The attached patch fixes the issue for me, though I'm not totally sure 
it's the *right* fix. Any thoughts? (I'm also not 100% sure this is the 
same issue you're seeing...)

[-- Attachment #2: 0001-Fix-segmentation-fault-when-merging-faces-in-a-nonin.patch --]
[-- Type: text/plain, Size: 1093 bytes --]

From bcc1c44dcfaeab391cd85ec104ffa279f28409e4 Mon Sep 17 00:00:00 2001
From: Jim Porter <jporterbugs@gmail.com>
Date: Thu, 23 Feb 2023 18:16:28 -0800
Subject: [PATCH] Fix segmentation fault when merging faces in a noninteractive
 Emacs

* src/xfaces.c (internal-merge-in-global-face): Signal an error when
'noninteractive' is true.
---
 src/xfaces.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/src/xfaces.c b/src/xfaces.c
index 62d7823f308..0310d328b8f 100644
--- a/src/xfaces.c
+++ b/src/xfaces.c
@@ -4162,6 +4162,13 @@ DEFUN ("internal-merge-in-global-face", Finternal_merge_in_global_face,
   Lisp_Object global_lface, local_lface, *gvec, *lvec;
   struct frame *f = XFRAME (frame);
 
+  /* If this process is noninteractive, we likely don't have a face
+     cache, so attempts to use it below would segfault.  */
+  if (noninteractive)
+    {
+      error ("Attempt to merge faces in noninteractive Emacs");
+    }
+
   CHECK_LIVE_FRAME (frame);
   global_lface = lface_from_face_name (NULL, face, true);
   local_lface = lface_from_face_name (f, face, false);
-- 
2.25.1

Re: server.el test failures (was: Re: bug#9800: Incomplete truncated file buffers from the /proc filesystem)

[Po Lu]

Please remove the redundant braces after ``if (noninteractive)''.  Thanks.

On February 24, 2023 10:20:39 AM GMT+08:00, Jim Porter <jporterbugs@gmail.com> wrote:
>On 2/23/2023 4:50 PM, Jim Porter wrote:
>> Since the last message I posted, I'm now also seeing this test fail, though I get a segfault instead. I bisected this to commit a555abc56d5270cebe94f904189526d7ac433a94 ("Fix order of faces in 'face-list'").
>> 
>> I'm pretty surprised by this, since that patch is *very* simple, but I can reliably segfault with it, and never segfault without it. I'll keep digging to see what's going on here.
>
>The segfault is in FACE_FROM_ID_OR_NULL, called from Finternal_merge_in_global_face. It happens because the face_cache is null during these tests (since Emacs is noninteractive).
>
>The attached patch fixes the issue for me, though I'm not totally sure it's the *right* fix. Any thoughts? (I'm also not 100% sure this is the same issue you're seeing...)

Re: server.el test failures (was: Re: bug#9800: Incomplete truncated file buffers from the /proc filesystem)

[Jim Porter]

[-- Attachment #1: Type: text/plain, Size: 245 bytes --]

On 2/23/2023 7:25 PM, Po Lu wrote:
> Please remove the redundant braces after ``if (noninteractive)''.  Thanks.

Oh yeah. I had some vague recollection that Emacs preferred braces 
there, but I'm clearly confusing it with another project. Fixed.

[-- Attachment #2: 0001-Fix-segmentation-fault-when-merging-faces-in-a-nonin.patch --]
[-- Type: text/plain, Size: 1075 bytes --]

From df374dc2053b193b5c98c36e3ddd4c38e45f23b8 Mon Sep 17 00:00:00 2001
From: Jim Porter <jporterbugs@gmail.com>
Date: Thu, 23 Feb 2023 18:16:28 -0800
Subject: [PATCH] Fix segmentation fault when merging faces in a noninteractive
 Emacs

* src/xfaces.c (internal-merge-in-global-face): Signal an error when
'noninteractive' is true.
---
 src/xfaces.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/src/xfaces.c b/src/xfaces.c
index 62d7823f308..e1900f4cedb 100644
--- a/src/xfaces.c
+++ b/src/xfaces.c
@@ -4162,6 +4162,11 @@ DEFUN ("internal-merge-in-global-face", Finternal_merge_in_global_face,
   Lisp_Object global_lface, local_lface, *gvec, *lvec;
   struct frame *f = XFRAME (frame);
 
+  /* If this process is noninteractive, we likely don't have a face
+     cache, so attempts to use it below would segfault.  */
+  if (noninteractive)
+    error ("Attempt to merge faces in noninteractive Emacs");
+
   CHECK_LIVE_FRAME (frame);
   global_lface = lface_from_face_name (NULL, face, true);
   local_lface = lface_from_face_name (f, face, false);
-- 
2.25.1

Re: server.el test failures (was: Re: bug#9800: Incomplete truncated file buffers from the /proc filesystem)

[Eli Zaretskii]

> Date: Thu, 23 Feb 2023 18:20:39 -0800
> From: Jim Porter <jporterbugs@gmail.com>
> Cc: emacs-devel@gnu.org
> 
> On 2/23/2023 4:50 PM, Jim Porter wrote:
> > Since the last message I posted, I'm now also seeing this test fail, 
> > though I get a segfault instead. I bisected this to commit 
> > a555abc56d5270cebe94f904189526d7ac433a94 ("Fix order of faces in 
> > 'face-list'").
> > 
> > I'm pretty surprised by this, since that patch is *very* simple, but I 
> > can reliably segfault with it, and never segfault without it. I'll keep 
> > digging to see what's going on here.
> 
> The segfault is in FACE_FROM_ID_OR_NULL, called from 
> Finternal_merge_in_global_face. It happens because the face_cache is 
> null during these tests (since Emacs is noninteractive).
> 
> The attached patch fixes the issue for me, though I'm not totally sure 
> it's the *right* fix. Any thoughts? (I'm also not 100% sure this is the 
> same issue you're seeing...)

Please show the C backtrace from the crash, and include the Lisp
backtrace (the "xbacktrace" command in src/.gdbinit).

Why do you think a frame's face cache doesn't exist in noninteractive
sessions?  Such a session does have a (small) frame, and that frame
does have a face cache.  Here, try this with the emacs-29 branch:

 $ gdb ./emacs
 ...
 (gdb) break xfaces.c:4193
 (gdb) r -batch --eval "(insert (propertize \" \" 'face '(:forground \"red\")))"

When the breakpoint breaks, you will see:

  (gdb) p c
  $1 = (struct face_cache *) 0x6beeb78
  (gdb) p c->used
  $2 = 19

So in this case there is a face cache for the frame, and it has 19
faces cached.

Therefore, I think there's more here than meets the eye.  The frame's
face cache might be empty because some code caused us to do so (we do
that when a new face is added), in which case TRT to do is to
recompute all the basic faces.  But first we need to try to understand
what exactly caused the cache to be emptied.

Re: server.el test failures (was: Re: bug#9800: Incomplete truncated file buffers from the /proc filesystem)

[Jim Porter]

[-- Attachment #1: Type: text/plain, Size: 1377 bytes --]

On 2/23/2023 11:52 PM, Eli Zaretskii wrote:
>> Date: Thu, 23 Feb 2023 18:20:39 -0800
>> From: Jim Porter <jporterbugs@gmail.com>
>> Cc: emacs-devel@gnu.org
>>
>> The segfault is in FACE_FROM_ID_OR_NULL, called from
>> Finternal_merge_in_global_face. It happens because the face_cache is
>> null during these tests (since Emacs is noninteractive).
>>
>> The attached patch fixes the issue for me, though I'm not totally sure
>> it's the *right* fix. Any thoughts? (I'm also not 100% sure this is the
>> same issue you're seeing...)
> 
> Please show the C backtrace from the crash, and include the Lisp
> backtrace (the "xbacktrace" command in src/.gdbinit).

Ok, I ran Emacs (master branch) under GDB with the following arguments:

   -Q -L ":../test" -l ert -l lisp/server-tests.el --batch --eval 
'(ert-run-tests-batch-and-exit (quote (not (or (tag :unstable) (tag 
:nativecomp)))))'

Attached is the backtrace from 'xbacktrace'.

I think this only occurs when starting the Emacs server in a batch-mode 
Emacs process and then starting a client via "emacsclient -c". I see the 
segfault when running any of the tests in test/lisp/server-tests.el that 
create a frame (e.g. 'server-tests/server-start/stop-prompt-with-client').

This also only seems to occur if the first face that 
'face-set-after-frame-default' passes to 'internal-merge-in-global-face' 
is the default face.

[-- Attachment #2: gdb.txt --]
[-- Type: text/plain, Size: 15775 bytes --]

#0  raise (sig=sig@entry=11) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x000055f8d6289ccb in terminate_due_to_signal
    (sig=sig@entry=11, backtrace_limit=backtrace_limit@entry=40)
    at ../../src/emacs.c:464
#2  0x000055f8d628a211 in handle_fatal_signal (sig=sig@entry=11)
    at ../../src/sysdep.c:1783
#3  0x000055f8d63db97d in deliver_thread_signal
    (sig=sig@entry=11, handler=0x55f8d628a200 <handle_fatal_signal>)
    at ../../src/sysdep.c:1775
#4  0x000055f8d63db9fd in deliver_fatal_thread_signal (sig=11)
    at ../../src/sysdep.c:1795
#5  handle_sigsegv (sig=11, siginfo=<optimized out>, arg=<optimized out>)
    at ../../src/sysdep.c:1888
#6  0x00007f6278d7d420 in <signal handler called> ()
    at /lib/x86_64-linux-gnu/libpthread.so.0
#7  FACE_FROM_ID_OR_NULL (f=0x55f8d85f2f28, id=0) at ../../src/frame.h:1505
#8  Finternal_merge_in_global_face (face=<optimized out>, frame=0x55f8d85f2f2d)
    at ../../src/xfaces.c:4189
#9  0x000055f8d6494517 in exec_byte_code
    (fun=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>) at ../../src/bytecode.c:809
#10 0x000055f8d644a0f0 in Ffuncall (nargs=2, args=0x7f62740477b8)
    at ../../src/eval.c:2997
#11 0x000055f8d644a5b2 in Fapply (nargs=2, args=0x7f62740477b8)
    at ../../src/eval.c:2625
#12 0x000055f8d6494517 in exec_byte_code
    (fun=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>) at ../../src/bytecode.c:809
#13 0x000055f8d644a0f0 in Ffuncall (nargs=3, args=0x7ffd8d875470)
    at ../../src/eval.c:2997
#14 0x000055f8d644a428 in Fapply
    (nargs=nargs@entry=2, args=args@entry=0x7ffd8d875510)
    at ../../src/eval.c:2668
#15 0x000055f8d644a690 in apply1 (fn=<optimized out>, arg=<optimized out>)
    at ../../src/eval.c:2884
#16 0x000055f8d644898c in internal_condition_case_1
    (bfun=bfun@entry=0x55f8d64973d0 <read_process_output_call>, arg=0x55f8d85dd1f3, handlers=handlers@entry=0x0, hfun=hfun@entry=0x55f8d6497310 <read_process_output_error_handler>) at ../../src/eval.c:1498
#17 0x000055f8d649a4d7 in read_and_dispose_of_process_output
    (coding=0x55f8d85d13d0, nbytes=1564, chars=0x7ffd8d875570 "-env PWD=/home/jim/src/emacs/build/test -env OLDPWD=/home/jim/config/emacs.d/theme -env SSH_TTY=/dev/pts/0 -env DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus -env VIRTUALENVWRAPPER_HOOK_DIR=/h"..., p=0xfffffffffffffffb) at ../../src/process.c:6294
#18 read_process_output
    (proc=proc@entry=0x55f8d85e2855, channel=channel@entry=10)
    at ../../src/process.c:6204
#19 0x000055f8d64a0e1c in wait_reading_process_output
    (time_limit=time_limit@entry=0, nsecs=nsecs@entry=100000000, read_kbd=read_kbd@entry=0, do_display=do_display@entry=false, wait_for_cell=wait_for_cell@entry=0x0, wait_proc=wait_proc@entry=0x0, just_wait_proc=<optimized out>)
    at ../../src/process.c:5888
#20 0x000055f8d62935eb in Fsleep_for
    (seconds=<optimized out>, milliseconds=<optimized out>)
    at ../../src/lisp.h:1164
#21 0x000055f8d6494517 in exec_byte_code
    (fun=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>) at ../../src/bytecode.c:809
#22 0x000055f8d644f181 in apply_lambda
    (fun=<optimized out>, args=<optimized out>, count=count@entry=...)
    at ../../src/eval.c:3105
#23 0x000055f8d644dac6 in eval_sub (form=<optimized out>)
    at ../../src/eval.c:2590
#24 0x000055f8d644e22d in Fprogn (body=0x0, body@entry=0x55f8d855a083)
    at ../../src/eval.c:436
#25 0x000055f8d644eff5 in prog_ignore (body=0x55f8d855a083)
    at ../../src/eval.c:447
#26 Fwhile (args=<optimized out>) at ../../src/eval.c:1047
#27 0x000055f8d644e062 in eval_sub (form=<optimized out>)
    at ../../src/lisp.h:765
#28 0x000055f8d644e22d in Fprogn (body=0x0) at ../../src/eval.c:436
#29 0x000055f8d644f6fb in Flet (args=<optimized out>) at ../../src/lisp.h:765
#30 0x000055f8d644e062 in eval_sub (form=<optimized out>)
    at ../../src/lisp.h:765
#31 0x000055f8d644e22d in Fprogn (body=0x55f8d8558e63) at ../../src/eval.c:436
#32 0x000055f8d644f6fb in Flet (args=<optimized out>) at ../../src/lisp.h:765
#33 0x000055f8d644e062 in eval_sub (form=<optimized out>)
    at ../../src/lisp.h:765
#34 0x000055f8d644e22d in Fprogn (body=0x0) at ../../src/eval.c:436
#35 0x000055f8d644f6fb in Flet (args=<optimized out>) at ../../src/lisp.h:765
#36 0x000055f8d644e062 in eval_sub (form=<optimized out>)
    at ../../src/lisp.h:765
#37 0x000055f8d644e22d in Fprogn (body=0x0) at ../../src/eval.c:436
#38 0x000055f8d644e062 in eval_sub (form=<optimized out>)
    at ../../src/lisp.h:765
#39 0x000055f8d644fc48 in Funwind_protect (args=0x55f8d855e463)
    at ../../src/lisp.h:765
#40 0x000055f8d644e062 in eval_sub (form=<optimized out>)
    at ../../src/lisp.h:765
#41 0x000055f8d644e22d in Fprogn (body=0x0) at ../../src/eval.c:436
#42 0x000055f8d644f6fb in Flet (args=<optimized out>) at ../../src/lisp.h:765
#43 0x000055f8d644e062 in eval_sub (form=<optimized out>)
    at ../../src/lisp.h:765
#44 0x000055f8d644e22d in Fprogn (body=0x0) at ../../src/eval.c:436
#45 0x000055f8d644faec in FletX (args=0x55f8d8564ba3) at ../../src/lisp.h:765
#46 0x000055f8d644e062 in eval_sub (form=<optimized out>)
    at ../../src/lisp.h:765
#47 0x000055f8d644e22d in Fprogn (body=0x55f8d8563103) at ../../src/eval.c:436
#48 0x000055f8d644f6fb in Flet (args=<optimized out>) at ../../src/lisp.h:765
#49 0x000055f8d644e062 in eval_sub (form=<optimized out>)
    at ../../src/lisp.h:765
#50 0x000055f8d644e22d in Fprogn (body=0x0) at ../../src/eval.c:436
#51 0x000055f8d644e555 in funcall_lambda
    (fun=0x55f8d8576783, nargs=0, arg_vector=0x7f6274047468)
    at ../../src/eval.c:3235
#52 0x000055f8d6494662 in exec_byte_code
    (fun=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>) at ../../src/bytecode.c:811
#53 0x000055f8d644f181 in apply_lambda
    (fun=<optimized out>, args=<optimized out>, count=count@entry=...)
    at ../../src/eval.c:3105
#54 0x000055f8d644dac6 in eval_sub (form=<optimized out>)
    at ../../src/eval.c:2590
#55 0x000055f8d6450214 in Feval (form=0x55f8d85a4983, lexical=<optimized out>)
    at ../../src/eval.c:2363
#56 0x000055f8d6494517 in exec_byte_code
    (fun=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>) at ../../src/bytecode.c:809
#57 0x000055f8d644f181 in apply_lambda
    (fun=<optimized out>, args=<optimized out>, count=count@entry=...)
    at ../../src/eval.c:3105
#58 0x000055f8d644dac6 in eval_sub (form=<optimized out>)
    at ../../src/eval.c:2590
#59 0x000055f8d6450214 in Feval (form=0x7f6274c1500b, lexical=<optimized out>)
    at ../../src/eval.c:2363
#60 0x000055f8d64488f7 in internal_condition_case
    (bfun=bfun@entry=0x55f8d63bae70 <top_level_2>, handlers=handlers@entry=0x90, hfun=hfun@entry=0x55f8d63c1e90 <cmd_error>) at ../../src/eval.c:1474
#61 0x000055f8d63bca4a in top_level_1 (ignore=ignore@entry=0x0)
    at ../../src/keyboard.c:1141
#62 0x000055f8d6448839 in internal_catch
    (tag=tag@entry=0x10470, func=func@entry=0x55f8d63bca20 <top_level_1>, arg=arg@entry=0x0) at ../../src/eval.c:1197
#63 0x000055f8d63bada0 in command_loop () at ../../src/lisp.h:1164
#64 0x000055f8d63c19e7 in recursive_edit_1 () at ../../src/keyboard.c:711
#65 0x000055f8d63c1d90 in Frecursive_edit () at ../../src/keyboard.c:794
#66 0x000055f8d62922b0 in main (argc=<optimized out>, argv=<optimized out>)
    at ../../src/emacs.c:2530
Starting program: /home/jim/src/emacs/build/src/emacs -Q -L ":../test" -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 0x7fffeb196700 (LWP 612986)]
[Detaching after vfork from child process 612987]

Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
Finternal_merge_in_global_face (face=<optimized out>, 
    frame=XIL(0x555556174ec5)) at ../../src/xfaces.c:4189
4189	      struct face *newface, *oldface = FACE_FROM_ID_OR_NULL (f, DEFAULT_FACE_ID);
Undefined command: "Starting".  Try "help".
#0  Finternal_merge_in_global_face
    (face=<optimized out>, frame=XIL(0x555556174ec5))
    at ../../src/xfaces.c:4189
#1  0x00005555557b1517 in exec_byte_code
    (fun=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>) at ../../src/bytecode.c:809
#2  0x00005555557670f0 in Ffuncall (nargs=2, args=0x7fffeb1977b8)
    at ../../src/eval.c:2997
#3  0x00005555557675b2 in Fapply (nargs=2, args=0x7fffeb1977b8)
    at ../../src/eval.c:2625
#4  0x00005555557b1517 in exec_byte_code
    (fun=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>) at ../../src/bytecode.c:809
#5  0x00005555557670f0 in Ffuncall (nargs=3, args=0x7fffffffbc80)
    at ../../src/eval.c:2997
#6  0x0000555555767428 in Fapply
    (nargs=nargs@entry=2, args=args@entry=0x7fffffffbd20)
    at ../../src/eval.c:2668
#7  0x0000555555767690 in apply1 (fn=<optimized out>, arg=<optimized out>)
    at ../../src/eval.c:2884
#8  0x000055555576598c in internal_condition_case_1
    (bfun=bfun@entry=0x5555557b43d0 <read_process_output_call>, arg=XIL(0x555556166393), handlers=handlers@entry=XIL(0), hfun=hfun@entry=0x5555557b4310 <read_process_output_error_handler>) at ../../src/eval.c:1498
#9  0x00005555557b74d7 in read_and_dispose_of_process_output
    (coding=0x55555615a3e0, nbytes=1351, chars=0x7fffffffbd80 "-env PWD=/home/jim/src/emacs/build -env COLUMNS=80 -env LINES=75 -env _=/home/jim/src/emacs/build/src/emacs -env LD_LIBRARY_PATH=/home/jim/lib -env EDITOR=emacs -env LESSOPEN=|&_/home/jim/config/sourc"..., p=0xfffffffffffffffb) at ../../src/process.c:6294
#10 read_process_output
    (proc=proc@entry=XIL(0x555556169725), channel=channel@entry=10)
    at ../../src/process.c:6204
#11 0x00005555557bde1c in wait_reading_process_output
    (time_limit=time_limit@entry=0, nsecs=nsecs@entry=100000000, read_kbd=read_kbd@entry=0, do_display=do_display@entry=false, wait_for_cell=wait_for_cell@entry=XIL(0), wait_proc=wait_proc@entry=0x0, just_wait_proc=<optimized out>)
    at ../../src/process.c:5888
#12 0x00005555555b05eb in Fsleep_for
    (seconds=<optimized out>, milliseconds=<optimized out>)
    at ../../src/lisp.h:1164
#13 0x00005555557b1517 in exec_byte_code
    (fun=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>) at ../../src/bytecode.c:809
#14 0x000055555576c181 in apply_lambda
    (fun=<optimized out>, args=<optimized out>, count=count@entry=...)
    at ../../src/eval.c:3105
#15 0x000055555576aac6 in eval_sub (form=<optimized out>)
    at ../../src/eval.c:2590
#16 0x000055555576b22d in Fprogn (body=XIL(0), body@entry=XIL(0x5555560dee13))
    at ../../src/eval.c:436
#17 0x000055555576bff5 in prog_ignore (body=XIL(0x5555560dee13))
    at ../../src/eval.c:447
#18 Fwhile (args=<optimized out>) at ../../src/eval.c:1047
#19 0x000055555576b062 in eval_sub (form=<optimized out>)
    at ../../src/lisp.h:765
#20 0x000055555576b22d in Fprogn (body=XIL(0)) at ../../src/eval.c:436
#21 0x000055555576c6fb in Flet (args=<optimized out>) at ../../src/lisp.h:765
#22 0x000055555576b062 in eval_sub (form=<optimized out>)
    at ../../src/lisp.h:765
#23 0x000055555576b22d in Fprogn (body=XIL(0x5555560dd413))
    at ../../src/eval.c:436
#24 0x000055555576c6fb in Flet (args=<optimized out>) at ../../src/lisp.h:765
#25 0x000055555576b062 in eval_sub (form=<optimized out>)
    at ../../src/lisp.h:765
#26 0x000055555576b22d in Fprogn (body=XIL(0)) at ../../src/eval.c:436
#27 0x000055555576c6fb in Flet (args=<optimized out>) at ../../src/lisp.h:765
#28 0x000055555576b062 in eval_sub (form=<optimized out>)
    at ../../src/lisp.h:765
#29 0x000055555576b22d in Fprogn (body=XIL(0)) at ../../src/eval.c:436
#30 0x000055555576b062 in eval_sub (form=<optimized out>)
    at ../../src/lisp.h:765
#31 0x000055555576cc48 in Funwind_protect (args=XIL(0x5555560e39f3))
    at ../../src/lisp.h:765
#32 0x000055555576b062 in eval_sub (form=<optimized out>)
    at ../../src/lisp.h:765
#33 0x000055555576b22d in Fprogn (body=XIL(0)) at ../../src/eval.c:436
#34 0x000055555576c6fb in Flet (args=<optimized out>) at ../../src/lisp.h:765
#35 0x000055555576b062 in eval_sub (form=<optimized out>) at ../../src/lisp.h:765
#36 0x000055555576b22d in Fprogn (body=XIL(0)) at ../../src/eval.c:436
#37 0x000055555576caec in FletX (args=XIL(0x5555560e9953)) at ../../src/lisp.h:765
#38 0x000055555576b062 in eval_sub (form=<optimized out>) at ../../src/lisp.h:765
#39 0x000055555576b22d in Fprogn (body=XIL(0x5555560e8693)) at ../../src/eval.c:436
#40 0x000055555576c6fb in Flet (args=<optimized out>) at ../../src/lisp.h:765
#41 0x000055555576b062 in eval_sub (form=<optimized out>) at ../../src/lisp.h:765
#42 0x000055555576b22d in Fprogn (body=XIL(0)) at ../../src/eval.c:436
#43 0x000055555576b555 in funcall_lambda (fun=XIL(0x5555560fb533), nargs=0, arg_vector=0x7fffeb197468) at ../../src/eval.c:3235
#44 0x00005555557b1662 in exec_byte_code (fun=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>) at ../../src/bytecode.c:811
#45 0x000055555576c181 in apply_lambda (fun=<optimized out>, args=<optimized out>, count=count@entry=...) at ../../src/eval.c:3105
#46 0x000055555576aac6 in eval_sub (form=<optimized out>) at ../../src/eval.c:2590
#47 0x000055555576d214 in Feval (form=XIL(0x555556129f13), lexical=<optimized out>) at ../../src/eval.c:2363
#48 0x00005555557b1517 in exec_byte_code (fun=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>) at ../../src/bytecode.c:809
#49 0x000055555576c181 in apply_lambda (fun=<optimized out>, args=<optimized out>, count=count@entry=...) at ../../src/eval.c:3105
#50 0x000055555576aac6 in eval_sub (form=<optimized out>) at ../../src/eval.c:2590
#51 0x000055555576d214 in Feval (form=XIL(0x7fffec2d500b), lexical=<optimized out>) at ../../src/eval.c:2363
#52 0x00005555557658f7 in internal_condition_case (bfun=bfun@entry=0x5555556d7e70 <top_level_2>, handlers=handlers@entry=XIL(0x90), hfun=hfun@entry=0x5555556dee90 <cmd_error>) at ../../src/eval.c:1474
#53 0x00005555556d9a4a in top_level_1 (ignore=ignore@entry=XIL(0)) at ../../src/keyboard.c:1141
#54 0x0000555555765839 in internal_catch (tag=tag@entry=XIL(0x10470), func=func@entry=0x5555556d9a20 <top_level_1>, arg=arg@entry=XIL(0)) at ../../src/eval.c:1197
#55 0x00005555556d7da0 in command_loop () at ../../src/lisp.h:1164
#56 0x00005555556de9e7 in recursive_edit_1 () at ../../src/keyboard.c:711
#57 0x00005555556ded90 in Frecursive_edit () at ../../src/keyboard.c:794
#58 0x00005555555af2b0 in main (argc=<optimized out>, argv=<optimized out>) at ../../src/emacs.c:2530

Lisp Backtrace:
"internal-merge-in-global-face" (0xeb1978f8)
"face-set-after-frame-default" (0xeb197898)
"tty-create-frame-with-faces" (0xeb197840)
0xebef9760 PVEC_COMPILED
"apply" (0xeb1977b8)
"frame-creation-function" (0xeb197758)
"make-frame" (0xeb1976d8)
"server--create-frame" (0xeb197658)
"server-create-tty-frame" (0xeb1975b8)
"server-process-filter" (0xffffbc88)
"sleep-for" (0xeb1974d8)
"sit-for" (0xffffd390)
"while" (0xffffd538)
"let" (0xffffd6a8)
"let" (0xffffd818)
"let" (0xffffd998)
"progn" (0xffffda78)
"unwind-protect" (0xffffdb58)
"let" (0xffffdcc8)
"let*" (0xffffde18)
"let" (0xffffdf88)
0x560fb540 Lisp type 3
"ert--run-test-internal" (0xeb1973f8)
"ert-run-test" (0xeb197388)
"ert-run-or-rerun-test" (0xeb197318)
"ert-run-tests" (0xeb197290)
"ert-run-tests-batch" (0xeb197238)
"ert-run-tests-batch-and-exit" (0xffffe150)
"eval" (0xeb1971c0)
"command-line-1" (0xeb1970b8)
"command-line" (0xeb197040)
"normal-top-level" (0xffffe350)

Re: server.el test failures (was: Re: bug#9800: Incomplete truncated file buffers from the /proc filesystem)

[Eli Zaretskii]

> Date: Fri, 24 Feb 2023 09:48:02 -0800
> Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org
> From: Jim Porter <jporterbugs@gmail.com>
> 
> On 2/23/2023 11:52 PM, Eli Zaretskii wrote:
> >> Date: Thu, 23 Feb 2023 18:20:39 -0800
> >> From: Jim Porter <jporterbugs@gmail.com>
> >> Cc: emacs-devel@gnu.org
> >>
> >> The segfault is in FACE_FROM_ID_OR_NULL, called from
> >> Finternal_merge_in_global_face. It happens because the face_cache is
> >> null during these tests (since Emacs is noninteractive).
> >>
> >> The attached patch fixes the issue for me, though I'm not totally sure
> >> it's the *right* fix. Any thoughts? (I'm also not 100% sure this is the
> >> same issue you're seeing...)
> > 
> > Please show the C backtrace from the crash, and include the Lisp
> > backtrace (the "xbacktrace" command in src/.gdbinit).
> 
> Ok, I ran Emacs (master branch) under GDB with the following arguments:
> 
>    -Q -L ":../test" -l ert -l lisp/server-tests.el --batch --eval 
> '(ert-run-tests-batch-and-exit (quote (not (or (tag :unstable) (tag 
> :nativecomp)))))'
> 
> Attached is the backtrace from 'xbacktrace'.
> 
> I think this only occurs when starting the Emacs server in a batch-mode 
> Emacs process and then starting a client via "emacsclient -c". I see the 
> segfault when running any of the tests in test/lisp/server-tests.el that 
> create a frame (e.g. 'server-tests/server-start/stop-prompt-with-client').
> 
> This also only seems to occur if the first face that 
> 'face-set-after-frame-default' passes to 'internal-merge-in-global-face' 
> is the default face.

Thanks.  Does the patch below give good results?

diff --git a/src/xfaces.c b/src/xfaces.c
index 62d7823..37b7039 100644
--- a/src/xfaces.c
+++ b/src/xfaces.c
@@ -4186,7 +4186,9 @@ DEFUN ("internal-merge-in-global-face", Finternal_merge_in_global_face,
   if (EQ (face, Qdefault))
     {
       struct face_cache *c = FRAME_FACE_CACHE (f);
-      struct face *newface, *oldface = FACE_FROM_ID_OR_NULL (f, DEFAULT_FACE_ID);
+      struct face *newface;
+      struct face *oldface =
+	c ? FACE_FROM_ID_OR_NULL (f, DEFAULT_FACE_ID) : NULL;
       Lisp_Object attrs[LFACE_VECTOR_SIZE];
 
       /* This can be NULL (e.g., in batch mode).  */

Re: server.el test failures (was: Re: bug#9800: Incomplete truncated file buffers from the /proc filesystem)

[Alan Mackenzie]

Hello, Eli.

On Fri, Feb 24, 2023 at 20:37:25 +0200, Eli Zaretskii wrote:
> > Date: Fri, 24 Feb 2023 09:48:02 -0800
> > Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org
> > From: Jim Porter <jporterbugs@gmail.com>

[ .... ]

> Thanks.  Does the patch below give good results?

It fixes the errors I was seeing with server-tests.el, so I was probably
seeing the same problem as Jim.

Thanks!

> diff --git a/src/xfaces.c b/src/xfaces.c
> index 62d7823..37b7039 100644
> --- a/src/xfaces.c
> +++ b/src/xfaces.c
> @@ -4186,7 +4186,9 @@ DEFUN ("internal-merge-in-global-face", Finternal_merge_in_global_face,
>    if (EQ (face, Qdefault))
>      {
>        struct face_cache *c = FRAME_FACE_CACHE (f);
> -      struct face *newface, *oldface = FACE_FROM_ID_OR_NULL (f, DEFAULT_FACE_ID);
> +      struct face *newface;
> +      struct face *oldface =
> +	c ? FACE_FROM_ID_OR_NULL (f, DEFAULT_FACE_ID) : NULL;
>        Lisp_Object attrs[LFACE_VECTOR_SIZE];
 
>        /* This can be NULL (e.g., in batch mode).  */

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: server.el test failures (was: Re: bug#9800: Incomplete truncated file buffers from the /proc filesystem)

[Jim Porter]

On 2/24/2023 10:37 AM, Eli Zaretskii wrote:
>> Date: Fri, 24 Feb 2023 09:48:02 -0800
>> Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org
>> From: Jim Porter <jporterbugs@gmail.com>
>>
>> I think this only occurs when starting the Emacs server in a batch-mode
>> Emacs process and then starting a client via "emacsclient -c". I see the
>> segfault when running any of the tests in test/lisp/server-tests.el that
>> create a frame (e.g. 'server-tests/server-start/stop-prompt-with-client').
>>
>> This also only seems to occur if the first face that
>> 'face-set-after-frame-default' passes to 'internal-merge-in-global-face'
>> is the default face.
> 
> Thanks.  Does the patch below give good results?

Thanks, that fixes it for me.

Re: server.el test failures (was: Re: bug#9800: Incomplete truncated file buffers from the /proc filesystem)

[Eli Zaretskii]

> Date: Fri, 24 Feb 2023 12:31:23 -0800
> Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org
> From: Jim Porter <jporterbugs@gmail.com>
> 
> On 2/24/2023 10:37 AM, Eli Zaretskii wrote:
> >> Date: Fri, 24 Feb 2023 09:48:02 -0800
> >> Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org
> >> From: Jim Porter <jporterbugs@gmail.com>
> >>
> >> I think this only occurs when starting the Emacs server in a batch-mode
> >> Emacs process and then starting a client via "emacsclient -c". I see the
> >> segfault when running any of the tests in test/lisp/server-tests.el that
> >> create a frame (e.g. 'server-tests/server-start/stop-prompt-with-client').
> >>
> >> This also only seems to occur if the first face that
> >> 'face-set-after-frame-default' passes to 'internal-merge-in-global-face'
> >> is the default face.
> > 
> > Thanks.  Does the patch below give good results?
> 
> Thanks, that fixes it for me.

Thanks, installed on the emacs-29 branch.

Re: server.el test failures (was: Re: bug#9800: Incomplete truncated file buffers from the /proc filesystem)

[Paul Eggert]

On 2023-02-23 16:50, Jim Porter wrote:
> On 2/23/2023 3:42 PM, Paul Eggert wrote:
>> I tried running it on Fedora 37 x86-64 on a slow machine (AMD Phenom 
>> II X4 910e) and reproduced the timing bug. The output of 'make check' 
>> contained:
>>
>>      GEN      lisp/server-tests.log
>>    Running 7 tests (2023-02-23 09:45:51-0800, selector `(not (or (tag 
>> :expensive-test) (tag :unstable) (tag :nativecomp)))')
>>    make[3]: *** [Makefile:174: lisp/server-tests.log] Error 157
>>
>> I guess "Error 157" means signal 29 (157 - 128), which is SIGIO on 
>> this platform.
>>
>> This was with Emacs master (commit 
>> 6411a9af03a4eb1a82db47a9642b11ba7edaaaf0).
> 
> Since the last message I posted, I'm now also seeing this test fail, 
> though I get a segfault instead. I bisected this to commit 
> a555abc56d5270cebe94f904189526d7ac433a94 ("Fix order of faces in 
> 'face-list'").

Although I see a patch has been installed for that segfault, I'm still 
seeing a server-tests.el failure of the original kind with SIGIO, this 
time on a faster (though by no means bleeding edge) machine (a Xeon 
W-1350) running Ubuntu 22.10 with current patches. This is with current 
master (commit 8797e514ab68c12ed05d3af88e6baba64bf08f4d).

The SIGIO symptom this time contains a few more details, perhaps because 
Ubuntu's shell is chattier than Fedora's:

/bin/bash: line 3: 2442869 I/O possible            HOME=/nonexistent 
LANG=C 
EMACS_TEST_DIRECTORY=/home/eggert/src/gnu/emacs/static-checking/test 
"../src/emacs" --module-assertions --no-init-file --no-site-file 
--no-site-lisp -L ":." -l ert -l lisp/server-tests --batch --eval 
'(ert-run-tests-batch-and-exit (quote (not (or (tag :expensive-test) 
(tag :unstable) (tag :nativecomp)))))' > lisp/server-tests.log 2>&1
Running 7 tests (2023-02-26 00:13:56-0800, selector ‘(not (or (tag 
:expensive-test) (tag :unstable) (tag :nativecomp)))’)
make[3]: *** [Makefile:174: lisp/server-tests.log] Error 157


I'm also getting a failure with mule-tests:

Test sgml-html-meta-no-post-less-than-10lines backtrace:
   signal(ert-test-failed (((should (eq 'utf-8 (sgml-html-meta-run (con
   ert-fail(((should (eq 'utf-8 (sgml-html-meta-run (concat "\n\n\n\n\n
   #f(compiled-function () #<bytecode -0x1e01a52764337803>)()
   ert--run-test-internal(#s(ert--test-execution-info :test #s(ert-test
   ert-run-test(#s(ert-test :name sgml-html-meta-no-post-less-than-10li
   ert-run-or-rerun-test(#s(ert--stats :selector (not ...) :tests [...
   ert-run-tests((not (or (tag :expensive-test) (tag :unstable) (tag :n
   ert-run-tests-batch((not (or (tag :expensive-test) (tag :unstable) (
   ert-run-tests-batch-and-exit((not (or (tag :expensive-test) (tag :un
   eval((ert-run-tests-batch-and-exit '(not (or (tag :expensive-test) (
   command-line-1(("-L" ":." "-l" "ert" "-l" "lisp/international/mule-t
   command-line()
   normal-top-level()
Test sgml-html-meta-no-post-less-than-10lines condition:
     (ert-test-failed
      ((should
        (eq 'utf-8
	    (sgml-html-meta-run ...)))
       :form
       (eq utf-8 utf-8-unix)
       :value nil))
    FAILED   7/13  sgml-html-meta-no-post-less-than-10lines (0.000100 
sec) at lisp/international/mule-tests.el:119
    passed   8/13  sgml-html-meta-no-pre (0.000154 sec)
    passed   9/13  sgml-html-meta-none (0.000086 sec)
Warning: unknown coding system "XXX"
    passed  10/13  sgml-html-meta-unknown-coding (0.000092 sec)
    passed  11/13  sgml-html-meta-utf-8 (0.000073 sec)
    passed  12/13  sgml-html-meta-utf-8-with-bom (0.000072 sec)
    passed  13/13  sgml-html-meta-windows-hebrew (0.000071 sec)

Ran 13 tests, 12 results as expected, 1 unexpected (2023-02-26 
00:13:53-0800, 0.073256 sec)

1 unexpected results:
    FAILED  sgml-html-meta-no-post-less-than-10lines

make[3]: *** [Makefile:174: lisp/international/mule-tests.log] Error 1

Re: server.el test failures (was: Re: bug#9800: Incomplete truncated file buffers from the /proc filesystem)

[Eli Zaretskii]

> Date: Sun, 26 Feb 2023 00:29:59 -0800
> Cc: emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> 
> I'm also getting a failure with mule-tests:
> 
> Test sgml-html-meta-no-post-less-than-10lines backtrace:
>    signal(ert-test-failed (((should (eq 'utf-8 (sgml-html-meta-run (con
>    ert-fail(((should (eq 'utf-8 (sgml-html-meta-run (concat "\n\n\n\n\n
>    #f(compiled-function () #<bytecode -0x1e01a52764337803>)()
>    ert--run-test-internal(#s(ert--test-execution-info :test #s(ert-test
>    ert-run-test(#s(ert-test :name sgml-html-meta-no-post-less-than-10li
>    ert-run-or-rerun-test(#s(ert--stats :selector (not ...) :tests [...
>    ert-run-tests((not (or (tag :expensive-test) (tag :unstable) (tag :n
>    ert-run-tests-batch((not (or (tag :expensive-test) (tag :unstable) (
>    ert-run-tests-batch-and-exit((not (or (tag :expensive-test) (tag :un
>    eval((ert-run-tests-batch-and-exit '(not (or (tag :expensive-test) (
>    command-line-1(("-L" ":." "-l" "ert" "-l" "lisp/international/mule-t
>    command-line()
>    normal-top-level()
> Test sgml-html-meta-no-post-less-than-10lines condition:
>      (ert-test-failed
>       ((should
>         (eq 'utf-8
> 	    (sgml-html-meta-run ...)))
>        :form
>        (eq utf-8 utf-8-unix)
>        :value nil))
>     FAILED   7/13  sgml-html-meta-no-post-less-than-10lines (0.000100 
> sec) at lisp/international/mule-tests.el:119
>     passed   8/13  sgml-html-meta-no-pre (0.000154 sec)
>     passed   9/13  sgml-html-meta-none (0.000086 sec)
> Warning: unknown coding system "XXX"
>     passed  10/13  sgml-html-meta-unknown-coding (0.000092 sec)
>     passed  11/13  sgml-html-meta-utf-8 (0.000073 sec)
>     passed  12/13  sgml-html-meta-utf-8-with-bom (0.000072 sec)
>     passed  13/13  sgml-html-meta-windows-hebrew (0.000071 sec)
> 
> Ran 13 tests, 12 results as expected, 1 unexpected (2023-02-26 
> 00:13:53-0800, 0.073256 sec)
> 
> 1 unexpected results:
>     FAILED  sgml-html-meta-no-post-less-than-10lines

This is unrelated, and should be fixed now on the emacs-29 branch.

Re: server.el test failures (was: Re: bug#9800: Incomplete truncated file buffers from the /proc filesystem)

[Jim Porter]

On 2/26/2023 12:29 AM, Paul Eggert wrote:
> Although I see a patch has been installed for that segfault, I'm still 
> seeing a server-tests.el failure of the original kind with SIGIO, this 
> time on a faster (though by no means bleeding edge) machine (a Xeon 
> W-1350) running Ubuntu 22.10 with current patches. This is with current 
> master (commit 8797e514ab68c12ed05d3af88e6baba64bf08f4d).
> 
> The SIGIO symptom this time contains a few more details, perhaps because 
> Ubuntu's shell is chattier than Fedora's:

I've tried running these tests several times in various configurations, 
and I just can't reproduce it locally no matter what I do (on Linux 
Mint). Do you still see this failure if you run "make -C test 
server-tests"? That might help narrow down which test(s) are causing the 
SIGIO. If that doesn't help, maybe just try commenting out some of the 
tests in server-tests.el to see which ones are failing?

Sorry that's not very helpful on its own, but if we can narrow down 
where the issue is, I can take a stab at fixing it.

Re: server.el test failures

[Robert Pluim]

>>>>> On Sun, 26 Feb 2023 21:31:32 -0800, Jim Porter <jporterbugs@gmail.com> said:

    Jim> On 2/26/2023 12:29 AM, Paul Eggert wrote:
    >> Although I see a patch has been installed for that segfault, I'm
    >> still seeing a server-tests.el failure of the original kind with
    >> SIGIO, this time on a faster (though by no means bleeding edge)
    >> machine (a Xeon W-1350) running Ubuntu 22.10 with current
    >> patches. This is with current master (commit
    >> 8797e514ab68c12ed05d3af88e6baba64bf08f4d).
    >> The SIGIO symptom this time contains a few more details, perhaps
    >> because Ubuntu's shell is chattier than Fedora's:

    Jim> I've tried running these tests several times in various
    Jim> configurations, and I just can't reproduce it locally no matter what I
    Jim> do (on Linux Mint). Do you still see this failure if you run "make -C
    Jim> test server-tests"? That might help narrow down which test(s) are
    Jim> causing the SIGIO. If that doesn't help, maybe just try commenting out
    Jim> some of the tests in server-tests.el to see which ones are failing?

    Jim> Sorry that's not very helpful on its own, but if we can narrow down
    Jim> where the issue is, I can take a stab at fixing it.

I can make server-tests fail 100% on master and emacs-29 on Debian by
running the tests from inside emacs using vterm. I commented out all
the tests except server-tests/server-force-stop/keeps-frames

make -C test server-tests
make: Entering directory '/home/rpluim/repos/emacs/test'
make[1]: Entering directory '/home/rpluim/repos/emacs/test'
  ELC      lisp/server-tests.elc
  GEN      lisp/server-tests.log
Running 1 tests (2023-02-27 17:35:01+0100, selector `(not (or (tag :unstable) (tag :nativecomp)))')
make[1]: *** [Makefile:174: lisp/server-tests.log] I/O possible
make[1]: Leaving directory '/home/rpluim/repos/emacs/test'
make: *** [Makefile:240: lisp/server-tests] Error 2
make: Leaving directory '/home/rpluim/repos/emacs/test'
rltb:~/repos/emacs (master *)> 

Robert
-- 

Re: server.el test failures

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: Paul Eggert <eggert@cs.ucla.edu>,  emacs-devel@gnu.org
> Date: Mon, 27 Feb 2023 17:40:16 +0100
> 
> I can make server-tests fail 100% on master and emacs-29 on Debian by
> running the tests from inside emacs using vterm. I commented out all
> the tests except server-tests/server-force-stop/keeps-frames
> 
> make -C test server-tests
> make: Entering directory '/home/rpluim/repos/emacs/test'
> make[1]: Entering directory '/home/rpluim/repos/emacs/test'
>   ELC      lisp/server-tests.elc
>   GEN      lisp/server-tests.log
> Running 1 tests (2023-02-27 17:35:01+0100, selector `(not (or (tag :unstable) (tag :nativecomp)))')
> make[1]: *** [Makefile:174: lisp/server-tests.log] I/O possible
> make[1]: Leaving directory '/home/rpluim/repos/emacs/test'
> make: *** [Makefile:240: lisp/server-tests] Error 2
> make: Leaving directory '/home/rpluim/repos/emacs/test'
> rltb:~/repos/emacs (master *)> 

It's probably bogus, or the test is unstable, but just so we don't
give up easily: can you show a C and Lisp backtrace from the SIGIO
signal handler when it gets the signal in this case?

Re: server.el test failures

[Robert Pluim]

>>>>> On Mon, 27 Feb 2023 18:50:20 +0200, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Robert Pluim <rpluim@gmail.com>
    >> Cc: Paul Eggert <eggert@cs.ucla.edu>,  emacs-devel@gnu.org
    >> Date: Mon, 27 Feb 2023 17:40:16 +0100
    >> 
    >> I can make server-tests fail 100% on master and emacs-29 on Debian by
    >> running the tests from inside emacs using vterm. I commented out all
    >> the tests except server-tests/server-force-stop/keeps-frames
    >> 
    >> make -C test server-tests
    >> make: Entering directory '/home/rpluim/repos/emacs/test'
    >> make[1]: Entering directory '/home/rpluim/repos/emacs/test'
    >> ELC      lisp/server-tests.elc
    >> GEN      lisp/server-tests.log
    >> Running 1 tests (2023-02-27 17:35:01+0100, selector `(not (or (tag
    >> :unstable) (tag :nativecomp)))')
    >> make[1]: *** [Makefile:174: lisp/server-tests.log] I/O possible
    >> make[1]: Leaving directory '/home/rpluim/repos/emacs/test'
    >> make: *** [Makefile:240: lisp/server-tests] Error 2
    >> make: Leaving directory '/home/rpluim/repos/emacs/test'
    >> rltb:~/repos/emacs (master *)> 

    Eli> It's probably bogus, or the test is unstable, but just so we don't
    Eli> give up easily: can you show a C and Lisp backtrace from the SIGIO
    Eli> signal handler when it gets the signal in this case?

Iʼd love to, but our signal handler never gets called:

(gdb) b deliver_process_signal
Breakpoint 3 at 0x19d47e: deliver_process_signal. (2 locations)
(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 783192)]
Running 1 tests (2023-02-27 18:45:41+0100, selector `(not (or (tag :unstable) (tag :nativecomp)))')
[Detaching after vfork from child process 783193]
[New Thread 0x7ffff0992700 (LWP 783194)]
[New Thread 0x7fffeba46700 (LWP 783195)]
[Thread 0x7fffeba46700 (LWP 783195) exited]
[Thread 0x7ffff129d700 (LWP 783192) exited]
[Thread 0x7ffff22f8040 (LWP 783187) exited]

Program terminated with signal SIGIO, I/O possible.
The program no longer exists.

This is because we only install a SIGIO handler for interactive
sessions, so when I change that I get

Thread 1 "emacs" hit Breakpoint 3, deliver_process_signal (sig=29, 
    handler=0x5555556d1440 <handle_input_available_signal>) at sysdep.c:1726
1726	  int old_errno = errno;
(gdb) bt
#0  deliver_process_signal (sig=29, handler=0x5555556d1440 <handle_input_available_signal>) at sysdep.c:1726
#1  0x00007ffff5718140 in <signal handler called> () at /lib/x86_64-linux-gnu/libpthread.so.0
#2  0x00007ffff530fd2f in __GI___poll (fds=0x7fffffffa8b8, nfds=1, timeout=-1)
    at ../sysdeps/unix/sysv/linux/poll.c:29
#3  0x00007ffff6d92d02 in  () at /lib/x86_64-linux-gnu/libxcb.so.1
#4  0x00007ffff6d94d7f in  () at /lib/x86_64-linux-gnu/libxcb.so.1
#5  0x00007ffff6d94e91 in xcb_wait_for_reply () at /lib/x86_64-linux-gnu/libxcb.so.1
#6  0x00005555556a629b in x_term_init
    (display_name=display_name@entry=XIL(0x555556013664), xrm_option=xrm_option@entry=0x0, resource_name=0x55555600f870 "emacs") at xterm.c:30964
#7  0x00005555556a96c7 in Fx_open_connection
    (display=XIL(0x555556013664), xrm_string=<optimized out>, must_succeed=XIL(0)) at xfns.c:7548
#8  0x00005555557a2f15 in exec_byte_code
    (fun=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>)
    at bytecode.c:809
#9  0x000055555575d633 in Ffuncall (nargs=2, args=0x7ffff12b27c8) at eval.c:2997
#10 0x000055555575daf2 in Fapply (nargs=2, args=0x7ffff12b27c8) at eval.c:2625
#11 0x00005555557a2f15 in exec_byte_code
    (fun=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>)
    at bytecode.c:809
#12 0x000055555575d633 in Ffuncall (nargs=3, args=0x7fffffffb5f0) at eval.c:2997
#13 0x000055555575d850 in Fapply (nargs=nargs@entry=2, args=args@entry=0x7fffffffb680) at eval.c:2668
#14 0x000055555575dbbc in apply1 (fn=<optimized out>, arg=<optimized out>) at eval.c:2884
#15 0x000055555575be04 in internal_condition_case_1
    (bfun=bfun@entry=0x5555557a5bb0 <read_process_output_call>, arg=XIL(0x7ffff0a64f33), handlers=handlers@entry=XIL(0), hfun=hfun@entry=0x5555557a5af0 <read_process_output_error_handler>) at eval.c:1498
#16 0x00005555557a86bb in read_and_dispose_of_process_output
    (coding=0x555555ff6090, nbytes=3395, chars=0x7fffffffb6d0 "-env PWD=/home/rpluim/repos/emacs/test -env OLDPWD=/home/rpluim/repos/emacs -env DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus -env GDMSESSION=gnome-xorg -env HISTIGNORE=&&:[&_]*:exit:ls:bg:fg"..., p=0xfffffffffffffffb) at process.c:6307
#17 read_process_output (proc=proc@entry=XIL(0x555556000065), channel=channel@entry=10) at process.c:6217
#18 0x00005555557afe11 in wait_reading_process_output
    (time_limit=time_limit@entry=0, nsecs=nsecs@entry=100000000, read_kbd=read_kbd@entry=0, do_display=do_display@entry=false, wait_for_cell=wait_for_cell@entry=XIL(0), wait_proc=wait_proc@entry=0x0, just_wait_proc=<optimized out>)
    at process.c:5901
#19 0x00005555555aae9b in Fsleep_for (seconds=<optimized out>, milliseconds=<optimized out>) at lisp.h:1164
#20 0x00005555557a2f15 in exec_byte_code
    (fun=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>)
    at bytecode.c:809
#21 0x0000555555762797 in apply_lambda (fun=XIL(0x7ffff17d8845), args=<optimized out>, count=...) at eval.c:3105
#22 0x0000555555760e5d in eval_sub (form=<optimized out>) at eval.c:2590
#23 0x0000555555761b8d in Fprogn (body=XIL(0)) at eval.c:436
#24 prog_ignore (body=XIL(0x7ffff0a80b63)) at eval.c:447
#25 Fwhile (args=<optimized out>) at eval.c:1047
--Type <RET> for more, q to quit, c to continue without paging--c
#26 0x000055555576117a in eval_sub (form=<optimized out>) at lisp.h:765
#27 0x0000555555762d15 in Fprogn (body=XIL(0)) at eval.c:436
#28 Flet (args=XIL(0x7ffff0a80bc3)) at eval.c:1026
#29 0x000055555576117a in eval_sub (form=<optimized out>) at lisp.h:765
#30 0x0000555555762d15 in Fprogn (body=XIL(0x7ffff0a820a3)) at eval.c:436
#31 Flet (args=XIL(0x7ffff0a83ca3)) at eval.c:1026
#32 0x000055555576117a in eval_sub (form=<optimized out>) at lisp.h:765
#33 0x0000555555762d15 in Fprogn (body=XIL(0)) at eval.c:436
#34 Flet (args=XIL(0x7ffff0a83cd3)) at eval.c:1026
#35 0x000055555576117a in eval_sub (form=<optimized out>) at lisp.h:765
#36 0x000055555576146d in Fprogn (body=XIL(0x7ffff0a851b3)) at eval.c:436
#37 0x000055555576117a in eval_sub (form=<optimized out>) at lisp.h:765
#38 0x0000555555763287 in Funwind_protect (args=XIL(0x7ffff0a851d3)) at lisp.h:765
#39 0x000055555576117a in eval_sub (form=<optimized out>) at lisp.h:765
#40 0x0000555555762d15 in Fprogn (body=XIL(0)) at eval.c:436
#41 Flet (args=XIL(0x7ffff0a87b93)) at eval.c:1026
#42 0x000055555576117a in eval_sub (form=<optimized out>) at lisp.h:765
#43 0x00005555557630f5 in Fprogn (body=XIL(0)) at eval.c:436
#44 FletX (args=XIL(0x7ffff0a87bd3)) at eval.c:958
#45 0x000055555576117a in eval_sub (form=<optimized out>) at lisp.h:765
#46 0x0000555555763287 in Funwind_protect (args=XIL(0x7ffff0a87c03)) at lisp.h:765
#47 0x000055555576117a in eval_sub (form=<optimized out>) at lisp.h:765
#48 0x00005555557630f5 in Fprogn (body=XIL(0x7ffff0a780d3)) at eval.c:436
#49 FletX (args=XIL(0x7ffff0a780e3)) at eval.c:958
#50 0x000055555576117a in eval_sub (form=<optimized out>) at lisp.h:765
#51 0x000055555576203d in Fprogn (body=XIL(0)) at eval.c:436
#52 funcall_lambda (fun=XIL(0x7ffff0a75c53), nargs=0, arg_vector=0x7ffff12b2468) at eval.c:3235
#53 0x00005555557a30e1 in exec_byte_code (fun=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>) at bytecode.c:811
#54 0x0000555555762797 in apply_lambda (fun=XIL(0x555555f7f0a5), args=<optimized out>, count=...) at eval.c:3105
#55 0x0000555555760e5d in eval_sub (form=<optimized out>) at eval.c:2590
#56 0x0000555555763830 in Feval (form=XIL(0x7ffff0a75dd3), lexical=<optimized out>) at eval.c:2363
#57 0x00005555557a2f15 in exec_byte_code (fun=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>) at bytecode.c:809
#58 0x0000555555762797 in apply_lambda (fun=XIL(0x7ffff1ad0ff5), args=<optimized out>, count=...) at eval.c:3105
#59 0x0000555555760e5d in eval_sub (form=<optimized out>) at eval.c:2590
#60 0x0000555555763830 in Feval (form=XIL(0x7ffff1f07dbb), lexical=<optimized out>) at eval.c:2363
#61 0x000055555575bd77 in internal_condition_case (bfun=bfun@entry=0x5555556d1590 <top_level_2>, handlers=handlers@entry=XIL(0x90), hfun=hfun@entry=0x5555556d88e0 <cmd_error>) at eval.c:1474
#62 0x00005555556d1eb6 in top_level_1 (ignore=ignore@entry=XIL(0)) at keyboard.c:1141
#63 0x000055555575bcd1 in internal_catch (tag=tag@entry=XIL(0x103e0), func=func@entry=0x5555556d1e90 <top_level_1>, arg=arg@entry=XIL(0)) at eval.c:1197
#64 0x00005555556d1508 in command_loop () at lisp.h:1164
#65 0x00005555556d8493 in recursive_edit_1 () at keyboard.c:711
#66 0x00005555556d880c in Frecursive_edit () at keyboard.c:794
#67 0x00005555555a9e43 in main (argc=<optimized out>, argv=<optimized out>) at emacs.c:2530

Lisp Backtrace:
"x-open-connection" (0xf12b2850)
0xf1ad3f38 PVEC_COMPILED
"apply" (0xf12b27c8)
"window-system-initialization" (0xf12b2768)
"make-frame" (0xf12b26e8)
"server--create-frame" (0xf12b2670)
"server-create-window-system-frame" (0xf12b25b8)
"server-process-filter" (0xffffb5f8)
"sleep-for" (0xf12b24d8)
"sit-for" (0xffffccc0)
"while" (0xffffce40)
"let" (0xffffcf70)
"let" (0xffffd0a0)
"let" (0xffffd1e0)
"progn" (0xffffd2b0)
"unwind-protect" (0xffffd380)
"let" (0xffffd4b0)
"let*" (0xffffd5e0)
"unwind-protect" (0xffffd6b0)
"let*" (0xffffd7e0)
0xf0a75c60 Lisp type 3
"ert--run-test-internal" (0xf12b23f8)
"ert-run-test" (0xf12b2388)
"ert-run-or-rerun-test" (0xf12b2318)
"ert-run-tests" (0xf12b2290)
"ert-run-tests-batch" (0xf12b2238)
"ert-run-tests-batch-and-exit" (0xffffd980)
"eval" (0xf12b21c0)
"command-line-1" (0xf12b20b8)
"command-line" (0xf12b2040)
"normal-top-level" (0xffffdb50)

If I run that server test with the SIGIO handler installed it passes

Robert
-- 

Re: server.el test failures

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: jporterbugs@gmail.com,  eggert@cs.ucla.edu,  emacs-devel@gnu.org
> Date: Mon, 27 Feb 2023 19:14:54 +0100
> 
>     Eli> It's probably bogus, or the test is unstable, but just so we don't
>     Eli> give up easily: can you show a C and Lisp backtrace from the SIGIO
>     Eli> signal handler when it gets the signal in this case?
> 
> Iʼd love to, but our signal handler never gets called:
> 
> (gdb) b deliver_process_signal
> Breakpoint 3 at 0x19d47e: deliver_process_signal. (2 locations)
> (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 783192)]
> Running 1 tests (2023-02-27 18:45:41+0100, selector `(not (or (tag :unstable) (tag :nativecomp)))')
> [Detaching after vfork from child process 783193]
> [New Thread 0x7ffff0992700 (LWP 783194)]
> [New Thread 0x7fffeba46700 (LWP 783195)]
> [Thread 0x7fffeba46700 (LWP 783195) exited]
> [Thread 0x7ffff129d700 (LWP 783192) exited]
> [Thread 0x7ffff22f8040 (LWP 783187) exited]
> 
> Program terminated with signal SIGIO, I/O possible.
> The program no longer exists.

What does "handle SIGIO" say before you type "run"?  Try this:

  (gdb) handle SIGIO stop print

and then run the test in batch mode again.

Re: server.el test failures

[Robert Pluim]

>>>>> On Mon, 27 Feb 2023 20:39:28 +0200, Eli Zaretskii <eliz@gnu.org> said:

    Eli> What does "handle SIGIO" say before you type "run"?  Try this:

    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
#6  0x00005555557a2f15 in exec_byte_code (fun=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>) at bytecode.c:809
#7  0x000055555575d633 in Ffuncall (nargs=2, args=0x7ffff12b27c8) at eval.c:2997
#8  0x000055555575daf2 in Fapply (nargs=2, args=0x7ffff12b27c8) at eval.c:2625
#9  0x00005555557a2f15 in exec_byte_code (fun=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>) at bytecode.c:809
#10 0x000055555575d633 in Ffuncall (nargs=3, args=0x7fffffffb3d0) at eval.c:2997
#11 0x000055555575d850 in Fapply (nargs=nargs@entry=2, args=args@entry=0x7fffffffb460) at eval.c:2668
#12 0x000055555575dbbc in apply1 (fn=<optimized out>, arg=<optimized out>) at eval.c:2884
#13 0x000055555575be04 in internal_condition_case_1
    (bfun=bfun@entry=0x5555557a5bb0 <read_process_output_call>, arg=XIL(0x7ffff08d5073), handlers=handlers@entry=XIL(0), hfun=hfun@entry=0x5555557a5af0 <read_process_output_error_handler>) at eval.c:1498
#14 0x00005555557a86bb in read_and_dispose_of_process_output
    (coding=0x555555ff41a0, nbytes=3886, chars=0x7fffffffb4b0 "-env PWD=/home/rpluim/repos/emacs/test -env OLDPWD=/home/rpluim/repos/emacs -env GIO_LAUNCHED_DESKTOP_FILE=/usr/share/applications/terminator.desktop -env GIO_LAUNCHED_DESKTOP_FILE_PID=2330 -env DBUS_"..., p=0xfffffffffffffffb) at process.c:6307
#15 read_process_output (proc=proc@entry=XIL(0x555555fff8e5), channel=channel@entry=10) at process.c:6217
#16 0x00005555557afe11 in wait_reading_process_output
    (time_limit=time_limit@entry=0, nsecs=nsecs@entry=100000000, read_kbd=read_kbd@entry=0, do_display=do_display@entry=false, wait_for_cell=wait_for_cell@entry=XIL(0), wait_proc=wait_proc@entry=0x0, just_wait_proc=<optimized out>) at process.c:5901
#17 0x00005555555aae9b in Fsleep_for (seconds=<optimized out>, milliseconds=<optimized out>) at lisp.h:1164
#18 0x00005555557a2f15 in exec_byte_code (fun=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>) at bytecode.c:809
#19 0x0000555555762797 in apply_lambda (fun=XIL(0x7ffff17d8845), args=<optimized out>, count=...) at eval.c:3105
#20 0x0000555555760e5d in eval_sub (form=<optimized out>) at eval.c:2590
#21 0x0000555555761b8d in Fprogn (body=XIL(0)) at eval.c:436
#22 prog_ignore (body=XIL(0x7ffff08f0cc3)) at eval.c:447
#23 Fwhile (args=<optimized out>) at eval.c:1047
#24 0x000055555576117a in eval_sub (form=<optimized out>) at lisp.h:765
#25 0x0000555555762d15 in Fprogn (body=XIL(0)) at eval.c:436
#26 Flet (args=XIL(0x7ffff08f0d23)) at eval.c:1026
#27 0x000055555576117a in eval_sub (form=<optimized out>) at lisp.h:765
#28 0x0000555555762d15 in Fprogn (body=XIL(0x7ffff08f2203)) at eval.c:436
#29 Flet (args=XIL(0x7ffff08f3e03)) at eval.c:1026
#30 0x000055555576117a in eval_sub (form=<optimized out>) at lisp.h:765
#31 0x0000555555762d15 in Fprogn (body=XIL(0)) at eval.c:436
#32 Flet (args=XIL(0x7ffff08f3e33)) at eval.c:1026
#33 0x000055555576117a in eval_sub (form=<optimized out>) at lisp.h:765
#34 0x000055555576146d in Fprogn (body=XIL(0x7ffff08f5313)) at eval.c:436
#35 0x000055555576117a in eval_sub (form=<optimized out>) at lisp.h:765
#36 0x0000555555763287 in Funwind_protect (args=XIL(0x7ffff08f5333)) at lisp.h:765
#37 0x000055555576117a in eval_sub (form=<optimized out>) at lisp.h:765
#38 0x0000555555762d15 in Fprogn (body=XIL(0)) at eval.c:436
#39 Flet (args=XIL(0x7ffff08f7cf3)) at eval.c:1026
#40 0x000055555576117a in eval_sub (form=<optimized out>) at lisp.h:765
#41 0x00005555557630f5 in Fprogn (body=XIL(0)) at eval.c:436
#42 FletX (args=XIL(0x7ffff08f7d33)) at eval.c:958
#43 0x000055555576117a in eval_sub (form=<optimized out>) at lisp.h:765
#44 0x0000555555763287 in Funwind_protect (args=XIL(0x7ffff08f7d63)) at lisp.h:765
#45 0x000055555576117a in eval_sub (form=<optimized out>) at lisp.h:765
#46 0x00005555557630f5 in Fprogn (body=XIL(0x7ffff08e8233)) at eval.c:436
#47 FletX (args=XIL(0x7ffff08e8243)) at eval.c:958
#48 0x000055555576117a in eval_sub (form=<optimized out>) at lisp.h:765
#49 0x000055555576203d in Fprogn (body=XIL(0)) at eval.c:436
#50 funcall_lambda (fun=XIL(0x7ffff08e5db3), nargs=0, arg_vector=0x7ffff12b2468) at eval.c:3235
#51 0x00005555557a30e1 in exec_byte_code (fun=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>) at bytecode.c:811
#52 0x0000555555762797 in apply_lambda (fun=XIL(0x555555f7f395), args=<optimized out>, count=...) at eval.c:3105
#53 0x0000555555760e5d in eval_sub (form=<optimized out>) at eval.c:2590
#54 0x0000555555763830 in Feval (form=XIL(0x7ffff08e5f33), lexical=<optimized out>) at eval.c:2363
#55 0x00005555557a2f15 in exec_byte_code (fun=<optimized out>, args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>) at bytecode.c:809
#56 0x0000555555762797 in apply_lambda (fun=XIL(0x7ffff1ad0ff5), args=<optimized out>, count=...) at eval.c:3105
#57 0x0000555555760e5d in eval_sub (form=<optimized out>) at eval.c:2590
#58 0x0000555555763830 in Feval (form=XIL(0x7ffff1f07deb), lexical=<optimized out>) at eval.c:2363
#59 0x000055555575bd77 in internal_condition_case
    (bfun=bfun@entry=0x5555556d1590 <top_level_2>, handlers=handlers@entry=XIL(0x90), hfun=hfun@entry=0x5555556d88e0 <cmd_error>) at eval.c:1474
#60 0x00005555556d1eb6 in top_level_1 (ignore=ignore@entry=XIL(0)) at keyboard.c:1141
#61 0x000055555575bcd1 in internal_catch (tag=tag@entry=XIL(0x103e0), func=func@entry=0x5555556d1e90 <top_level_1>, arg=arg@entry=XIL(0)) at eval.c:1197
#62 0x00005555556d1508 in command_loop () at lisp.h:1164
#63 0x00005555556d8493 in recursive_edit_1 () at keyboard.c:711
#64 0x00005555556d880c in Frecursive_edit () at keyboard.c:794
#65 0x00005555555a9e43 in main (argc=<optimized out>, argv=<optimized out>) at emacs.c:2530

Thread 3 "gdbus" received signal SIGIO, I/O possible.
[Switching to Thread 0x7fffebfff700 (LWP 26170)]
0x00007ffff530fd2f in __GI___poll (fds=0x5555560b0ad0, nfds=2, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
29      in ../sysdeps/unix/sysv/linux/poll.c
The program received a signal in another thread while
making a function call from GDB.
Evaluation of the expression containing the function
(backtrace_top) will be abandoned.
When the function is done executing, GDB will silently stop.

Robert
-- 

Re: server.el test failures

[Eli Zaretskii]

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

Re: server.el test failures

[Robert Pluim]

>>>>> On Tue, 28 Feb 2023 14:13:27 +0200, Eli Zaretskii <eliz@gnu.org> said:
    >> #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

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

DISPLAY is set. The following

    set environment DISPLAY=

in gdb makes the test succeed.

The test does 'emacsclient -c', changing that to 'emacsclient -c -nw'
also makes the test succeed

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

I think the former would be better. Jim, since you wrote this test,
what do you think?

Robert
-- 

Re: server.el test failures

[Jim Porter]

On 2/28/2023 5:05 AM, Robert Pluim wrote:
>      Eli> Why does make-frame create a GUI X frame in a batch session?  (I've
>      Eli> seen that in your previous backtrace, but thought it was because you
>      Eli> ran that test in an interactive session.)

Ah ha, that's why I couldn't reproduce this. I usually run tests in an 
SSH session (most of my development work is in an isolated VM so I can 
throw it away if I mess something up really badly). Running within a GUI 
session, I see the error now.

> The test does 'emacsclient -c', changing that to 'emacsclient -c -nw'
> also makes the test succeed
> 
>      Eli> I don't think we should create GUI frames in batch, since the SIGIO
>      Eli> handler is not set, and we generally aren't prepared for receiving
>      Eli> it.  We should create a TTY frame instead, or maybe no frame at all.
> 
> I think the former would be better. Jim, since you wrote this test,
> what do you think?

We should definitely create a frame in these tests, since that's what 
the tests are trying to, well, test. (All the server tests are there to 
make sure that the usual things you might do with "emacsclient" work 
properly.)

This might be a real bug in Emacs: as Eli says, an Emacs server started 
in batch mode shouldn't create GUI frames, but on the other hand, this 
might be only be relevant to the regression tests (who starts an Emacs 
server in a batch session?). I wouldn't mind just adding "-nw" to all 
the "emacsclient -c" invocations in server-tests.el.

Re: server.el test failures

[Eli Zaretskii]

> Date: Tue, 28 Feb 2023 11:02:25 -0800
> Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org
> From: Jim Porter <jporterbugs@gmail.com>
> 
> >      Eli> I don't think we should create GUI frames in batch, since the SIGIO
> >      Eli> handler is not set, and we generally aren't prepared for receiving
> >      Eli> it.  We should create a TTY frame instead, or maybe no frame at all.
> > 
> > I think the former would be better. Jim, since you wrote this test,
> > what do you think?
> 
> We should definitely create a frame in these tests, since that's what 
> the tests are trying to, well, test. (All the server tests are there to 
> make sure that the usual things you might do with "emacsclient" work 
> properly.)
> 
> This might be a real bug in Emacs: as Eli says, an Emacs server started 
> in batch mode shouldn't create GUI frames, but on the other hand, this 
> might be only be relevant to the regression tests (who starts an Emacs 
> server in a batch session?). I wouldn't mind just adding "-nw" to all 
> the "emacsclient -c" invocations in server-tests.el.

How about changing make-frame on master to create a TTY frame in batch
sessions, even if DISPLAY is set in the environment?

Re: server.el test failures

[Jim Porter]

[-- Attachment #1: Type: text/plain, Size: 616 bytes --]

On 2/28/2023 11:23 AM, Eli Zaretskii wrote:
> How about changing make-frame on master to create a TTY frame in batch
> sessions, even if DISPLAY is set in the environment?

That could work. Just to see what would happen, I tried running the 
Emacs server in a batch session and then calling "emacsclient -c -nw":

   emacs -Q --batch --eval '(progn (server-start) (while t (sit-for 1)))'
   emacsclient -c -nw

Surprisingly, it seems to mostly work, although it echoes control 
characters to the screen.

Anyway, here's a patch for this. Maybe there's a better way to do it, 
but this seemed like the least-invasive.

[-- Attachment #2: 0001-Don-t-create-GUI-frames-in-batch-sessions.patch --]
[-- Type: text/plain, Size: 1258 bytes --]

From d399ca03c0d91da7ad2aa70e76284a13c49d453d Mon Sep 17 00:00:00 2001
From: Jim Porter <jporterbugs@gmail.com>
Date: Tue, 28 Feb 2023 11:35:21 -0800
Subject: [PATCH] Don't create GUI frames in batch sessions

This resolves an issue with running test/lisp/server-tests.el when
'DISPLAY' is set: the tests would start the Emacs server in a batch
session, and then request a new GUI frame.  However, that caused the
tests to terminate with SIGIO, since a batch Emacs doesn't set a SIGIO
handler.

Ref: <https://lists.gnu.org/archive/html/emacs-devel/2023-02/msg00879.html>

* lisp/frame.el (make-frame): Override the 'display' parameter in
batch sessions.
---
 lisp/frame.el | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/lisp/frame.el b/lisp/frame.el
index b820d5fcd96..03cbd26ca0a 100644
--- a/lisp/frame.el
+++ b/lisp/frame.el
@@ -871,6 +871,10 @@ make-frame
 frame the selected frame.  However, the window system may select
 the new frame according to its own rules."
   (interactive)
+  ;; When running in a batch session, we can't create a GUI frame.
+  (when noninteractive
+    (push '(display . nil) parameters))
+
   (let* ((display (cdr (assq 'display parameters)))
          (w (cond
              ((assq 'terminal parameters)
-- 
2.25.1

Re: server.el test failures

[Robert Pluim]

>>>>> On Tue, 28 Feb 2023 11:41:41 -0800, Jim Porter <jporterbugs@gmail.com> said:
    Jim> +  ;; When running in a batch session, we can't create a GUI frame.

Itʼs not that we canʼt, itʼs that we shouldnʼt. If we install a SIGIO
handler and run the test with DISPLAY set, a GUI frame appears
briefly.

    Jim> +  (when noninteractive
    Jim> +    (push '(display . nil) parameters))
    Jim> +

I think that might be better off using `alist-get' + `setf' to avoid
having two `display' elements in the parameters.

    Jim>    (let* ((display (cdr (assq 'display parameters)))
    Jim>           (w (cond
    Jim>               ((assq 'terminal parameters)
    Jim> -- 
    Jim> 2.25.1



Robert
-- 

Re: server.el test failures

[Jim Porter]

On 3/1/2023 12:22 AM, Robert Pluim wrote:
>>>>>> On Tue, 28 Feb 2023 11:41:41 -0800, Jim Porter <jporterbugs@gmail.com> said:
>      Jim> +  ;; When running in a batch session, we can't create a GUI frame.
> 
> Itʼs not that we canʼt, itʼs that we shouldnʼt. If we install a SIGIO
> handler and run the test with DISPLAY set, a GUI frame appears
> briefly.

Well, since we don't have a SIGIO handler (and merely adding one 
wouldn't be a useful change, it seems), I'd say "can't" applies for now 
at least. :)

But it would probably make sense to expand this comment to explain 
*why*, since it's not as informative as it could be...

>      Jim> +  (when noninteractive
>      Jim> +    (push '(display . nil) parameters))
>      Jim> +
> 
> I think that might be better off using `alist-get' + `setf' to avoid
> having two `display' elements in the parameters.

Would that be safe? Since 'parameters' is an argument, we don't actually 
know how it was created or if modifying in-place would be ok. If it were 
just a regular quoted list, using 'setf' could cause problems.

Re: server.el test failures

[Eli Zaretskii]

> Date: Thu, 2 Mar 2023 14:15:49 -0800
> Cc: Eli Zaretskii <eliz@gnu.org>, eggert@cs.ucla.edu, emacs-devel@gnu.org
> From: Jim Porter <jporterbugs@gmail.com>
> 
> On 3/1/2023 12:22 AM, Robert Pluim wrote:
> >>>>>> On Tue, 28 Feb 2023 11:41:41 -0800, Jim Porter <jporterbugs@gmail.com> said:
> >      Jim> +  ;; When running in a batch session, we can't create a GUI frame.
> > 
> > Itʼs not that we canʼt, itʼs that we shouldnʼt. If we install a SIGIO
> > handler and run the test with DISPLAY set, a GUI frame appears
> > briefly.
> 
> Well, since we don't have a SIGIO handler (and merely adding one 
> wouldn't be a useful change, it seems), I'd say "can't" applies for now 
> at least. :)
> 
> But it would probably make sense to expand this comment to explain 
> *why*, since it's not as informative as it could be...
> 
> >      Jim> +  (when noninteractive
> >      Jim> +    (push '(display . nil) parameters))
> >      Jim> +
> > 
> > I think that might be better off using `alist-get' + `setf' to avoid
> > having two `display' elements in the parameters.
> 
> Would that be safe? Since 'parameters' is an argument, we don't actually 
> know how it was created or if modifying in-place would be ok. If it were 
> just a regular quoted list, using 'setf' could cause problems.

If this aspect could be an issue, perhaps it is better to implement
the change without touching 'parameters' at all?  It isn't hard, it
just might make the change less elegant and slightly larger.

Re: server.el test failures

[Jim Porter]

On 3/2/2023 11:00 PM, Eli Zaretskii wrote:
>> Date: Thu, 2 Mar 2023 14:15:49 -0800
>> Cc: Eli Zaretskii <eliz@gnu.org>, eggert@cs.ucla.edu, emacs-devel@gnu.org
>> From: Jim Porter <jporterbugs@gmail.com>
>>
>> Would that be safe? Since 'parameters' is an argument, we don't actually
>> know how it was created or if modifying in-place would be ok. If it were
>> just a regular quoted list, using 'setf' could cause problems.
> 
> If this aspect could be an issue, perhaps it is better to implement
> the change without touching 'parameters' at all?  It isn't hard, it
> just might make the change less elegant and slightly larger.

Pushing onto the front of 'parameters' should be safe, in the sense that 
after 'make-frame' returns, the caller wouldn't be able to tell that we 
did anything to it. So long as the caller can't tell, I think it's ok.

However, there might be a better way to do this anyway; I'll think it over.

Re: server.el test failures

[Jim Porter]

[-- Attachment #1: Type: text/plain, Size: 1233 bytes --]

On 3/2/2023 11:15 PM, Jim Porter wrote:
> On 3/2/2023 11:00 PM, Eli Zaretskii wrote:
>>> Date: Thu, 2 Mar 2023 14:15:49 -0800
>>> Cc: Eli Zaretskii <eliz@gnu.org>, eggert@cs.ucla.edu, 
>>> emacs-devel@gnu.org
>>> From: Jim Porter <jporterbugs@gmail.com>
>>>
>>> Would that be safe? Since 'parameters' is an argument, we don't actually
>>> know how it was created or if modifying in-place would be ok. If it were
>>> just a regular quoted list, using 'setf' could cause problems.
>>
>> If this aspect could be an issue, perhaps it is better to implement
>> the change without touching 'parameters' at all?  It isn't hard, it
>> just might make the change less elegant and slightly larger.
> 
> Pushing onto the front of 'parameters' should be safe, in the sense that 
> after 'make-frame' returns, the caller wouldn't be able to tell that we 
> did anything to it. So long as the caller can't tell, I think it's ok.
> 
> However, there might be a better way to do this anyway; I'll think it over.

Ok, I think this is better. Now, instead of messing with 'parameters', 
when in batch mode, we just always treat the window-system as nil (i.e. 
create a terminal frame). I ran the server tests with this patch, and 
they all look good.

[-- Attachment #2: 0001-Don-t-create-GUI-frames-in-batch-sessions.patch --]
[-- Type: text/plain, Size: 1392 bytes --]

From 0c7f9f038a5b3ec27456696aaffa8f0f4042246e Mon Sep 17 00:00:00 2001
From: Jim Porter <jporterbugs@gmail.com>
Date: Tue, 28 Feb 2023 11:35:21 -0800
Subject: [PATCH] Don't create GUI frames in batch sessions

This resolves an issue with running test/lisp/server-tests.el when
'DISPLAY' is set: the tests would start the Emacs server in a batch
session, and then request a new GUI frame.  However, that caused the
tests to terminate with SIGIO, since a batch Emacs doesn't set a SIGIO
handler.

Ref: <https://lists.gnu.org/archive/html/emacs-devel/2023-02/msg00879.html>

* lisp/frame.el (make-frame): Always create a terminal frame in batch
sessions.
---
 lisp/frame.el | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/lisp/frame.el b/lisp/frame.el
index b820d5fcd96..d9255a55171 100644
--- a/lisp/frame.el
+++ b/lisp/frame.el
@@ -873,6 +873,11 @@ make-frame
   (interactive)
   (let* ((display (cdr (assq 'display parameters)))
          (w (cond
+             ;; When running in a batch session, don't create a GUI
+             ;; frame.  (Batch sessions don't set a SIGIO handler on
+             ;; relevant platforms, so attempting this would terminate
+             ;; Emacs.)
+             (noninteractive nil)
              ((assq 'terminal parameters)
               (let ((type (terminal-live-p
                            (cdr (assq 'terminal parameters)))))
-- 
2.25.1

Re: server.el test failures

[Eli Zaretskii]

> Date: Fri, 3 Mar 2023 00:00:31 -0800
> From: Jim Porter <jporterbugs@gmail.com>
> Cc: rpluim@gmail.com, eggert@cs.ucla.edu, emacs-devel@gnu.org
> 
> Ok, I think this is better. Now, instead of messing with 'parameters', 
> when in batch mode, we just always treat the window-system as nil (i.e. 
> create a terminal frame). I ran the server tests with this patch, and 
> they all look good.

Thanks, this LGTM.  Please install on the emacs-29 branch.

Re: server.el test failures

[Jim Porter]

On 3/3/2023 12:10 AM, Eli Zaretskii wrote:
>> Date: Fri, 3 Mar 2023 00:00:31 -0800
>> From: Jim Porter <jporterbugs@gmail.com>
>> Cc: rpluim@gmail.com, eggert@cs.ucla.edu, emacs-devel@gnu.org
>>
>> Ok, I think this is better. Now, instead of messing with 'parameters',
>> when in batch mode, we just always treat the window-system as nil (i.e.
>> create a terminal frame). I ran the server tests with this patch, and
>> they all look good.
> 
> Thanks, this LGTM.  Please install on the emacs-29 branch.

Thanks. Pushed as 0c7f9f038a.

Re: server.el test failures

[Robert Pluim]

>>>>> On Fri, 3 Mar 2023 00:00:31 -0800, Jim Porter <jporterbugs@gmail.com> said:

    Jim> Ok, I think this is better. Now, instead of messing with 'parameters',
    Jim> when in batch mode, we just always treat the window-system as nil
    Jim> (i.e. create a terminal frame). I ran the server tests with this
    Jim> patch, and they all look good.

This looks even better than the previous patch.

Thanks

Robert
--