bug#9800: Incomplete truncated file buffers from the /proc filesystem

bug#9800: Incomplete truncated file buffers from the /proc filesystem

[Juri Linkov]

Large files from the /proc filesystem are visited incompletely,
their file buffers are truncated at the position 65536.
One possible test case to reproduce this is to load enough libraries
with e.g. (imagemagick-register-types) and visit Emacs's maps file
in /proc/$PID/maps.

Andreas said in http://lists.gnu.org/archive/html/emacs-devel/2011-10/msg00782.html
that it's due to this code in `insert-file-contents':

	  /* The file size returned from stat may be zero, but data
	     may be readable nonetheless, for example when this is a
	     file in the /proc filesystem.  */
	  if (end_offset == 0)
	    end_offset = READ_BUF_SIZE;

How this could be fixed?  Should it keep reading while more data can be
read from the file?

bug#9800: Incomplete truncated file buffers from the /proc filesystem

[Eli Zaretskii]

> From: Juri Linkov <juri@jurta.org>
> Date: Thu, 20 Oct 2011 01:59:42 +0300
> 
> Large files from the /proc filesystem are visited incompletely,
> their file buffers are truncated at the position 65536.
> One possible test case to reproduce this is to load enough libraries
> with e.g. (imagemagick-register-types) and visit Emacs's maps file
> in /proc/$PID/maps.
> 
> Andreas said in http://lists.gnu.org/archive/html/emacs-devel/2011-10/msg00782.html
> that it's due to this code in `insert-file-contents':
> 
> 	  /* The file size returned from stat may be zero, but data
> 	     may be readable nonetheless, for example when this is a
> 	     file in the /proc filesystem.  */
> 	  if (end_offset == 0)
> 	    end_offset = READ_BUF_SIZE;
> 
> How this could be fixed?  Should it keep reading while more data can be
> read from the file?

Does lseek work on these files?  If so, we could use something like

   lseek (fd, 0L, SEEK_END)

to find its size.  Or we could treat those files as non-regular, where
we set end_offset to TYPE_MAXIMUM (off_t) -- would that work with
these files?

bug#9800: Incomplete truncated file buffers from the /proc filesystem

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> Does lseek work on these files?

No.  The contents are completely dynamic, generated on-the-fly when
reading.

> Or we could treat those files as non-regular,

That is the only option.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#9800: Incomplete truncated file buffers from the /proc filesystem

[Paul Eggert]

It strikes me that regular files can go as you read them, too,
and that Emacs is not doing this properly.  That is, Emacs should
be fixed so that it continues to read from a growing regular file
until a proper EOF is reached (i.e., until read returns 0).

If Emacs is fixed in this way, it will read these /proc files
correctly too.

bug#9800: Incomplete truncated file buffers from the /proc filesystem

[Richard Stallman]

    It strikes me that regular files can go as you read them, too,
    and that Emacs is not doing this properly.  That is, Emacs should
    be fixed so that it continues to read from a growing regular file
    until a proper EOF is reached (i.e., until read returns 0).

I think there was a reason for doing it this way.  Perhaps so as to
allocate the space before reading the file.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

bug#9800: Incomplete truncated file buffers from the /proc filesystem

[Paul Eggert]

On 10/24/11 14:50, Richard Stallman wrote:
> I think there was a reason for doing it this way.  Perhaps so as to
> allocate the space before reading the file.

Yes, that sounds right.  And in the typical case where the file is not
growing, that allocates space efficiently.  If the file is growing, though,
it's OK to allocate more space after discovering that the initial
allocation was too small.

bug#9800: Incomplete truncated file buffers from the /proc filesystem

[Lars Magne Ingebrigtsen]

Paul Eggert <eggert@cs.ucla.edu> writes:

> It strikes me that regular files can go as you read them, too,
> and that Emacs is not doing this properly.  That is, Emacs should
> be fixed so that it continues to read from a growing regular file
> until a proper EOF is reached (i.e., until read returns 0).

Sounds like a good idea, but remember to bail out some time before
reading the infinitely big files to the very end.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

bug#9800: Incomplete truncated file buffers from the /proc filesystem

[Juri Linkov]

>> It strikes me that regular files can go as you read them, too,
>> and that Emacs is not doing this properly.  That is, Emacs should
>> be fixed so that it continues to read from a growing regular file
>> until a proper EOF is reached (i.e., until read returns 0).
>
> Sounds like a good idea, but remember to bail out some time before
> reading the infinitely big files to the very end.  :-)

Maybe limit the reading by the value of `large-file-warning-threshold'.

bug#9800: Incomplete truncated file buffers from the /proc filesystem

[Eli Zaretskii]

> From: Juri Linkov <juri@jurta.org>
> Date: Fri, 04 Nov 2011 11:36:01 +0200
> Cc: Paul Eggert <eggert@cs.ucla.edu>, 9800@debbugs.gnu.org
> 
> >> It strikes me that regular files can go as you read them, too,
> >> and that Emacs is not doing this properly.  That is, Emacs should
> >> be fixed so that it continues to read from a growing regular file
> >> until a proper EOF is reached (i.e., until read returns 0).
> >
> > Sounds like a good idea, but remember to bail out some time before
> > reading the infinitely big files to the very end.  :-)
> 
> Maybe limit the reading by the value of `large-file-warning-threshold'.

IMO, that value is ridiculously low for such use.  Maybe multiply it
by some large factor.

bug#9800: Incomplete truncated file buffers from the /proc filesystem

[Lars Ingebrigtsen]

Juri Linkov <juri@jurta.org> writes:

> Large files from the /proc filesystem are visited incompletely,
> their file buffers are truncated at the position 65536.

It seems like this issue has been exacerbated somewhat since this was
reported.

(with-temp-buffer
  (insert-file-contents "/proc/cpuinfo")
  (buffer-size))
=> 16384

(with-temp-buffer
  (call-process "cat" nil t nil "/proc/cpuinfo")
  (buffer-size))
=> 24626

But perhaps it's dependent on the block size.  (This is on
Debian/bookworm with Emacs 29.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#9800: Incomplete truncated file buffers from the /proc filesystem

[Juri Linkov]

>> Large files from the /proc filesystem are visited incompletely,
>> their file buffers are truncated at the position 65536.
>
> It seems like this issue has been exacerbated somewhat since this was
> reported.
>
> (with-temp-buffer
>   (insert-file-contents "/proc/cpuinfo")
>   (buffer-size))
> => 16384
>
> (with-temp-buffer
>   (call-process "cat" nil t nil "/proc/cpuinfo")
>   (buffer-size))
> => 24626
>
> But perhaps it's dependent on the block size.  (This is on
> Debian/bookworm with Emacs 29.)

I confirm that the block size now is decreased from 65536 to 16384,
so more buffers are truncated.

bug#9800: Incomplete truncated file buffers from the /proc filesystem

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Date: Thu, 20 Oct 2011 10:44:57 +0200
> Cc: Juri Linkov <juri@jurta.org>, 9800@debbugs.gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Does lseek work on these files?
> 
> No.  The contents are completely dynamic, generated on-the-fly when
> reading.
> 
> > Or we could treat those files as non-regular,
> 
> That is the only option.

Are all the files in "/proc" of this nature?  If so, we could consider
all of the files in that directory non-regular; if that is all that's
needed to visit /proc/foo files, insert-file-contents already has code
to deal with non-regular files.

Paul, do you see any downsides to such heuristic?  We could make it a
user option if the heuristic could sometimes backfire, I guess.

bug#9800: Incomplete truncated file buffers from the /proc filesystem

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

There is /proc/config.gz which does report a size, contrary to other files which report a size of 0. 

> On Feb 12, 2023, at 15:41, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> 
>> 
>> From: Andreas Schwab <schwab@linux-m68k.org>
>> Date: Thu, 20 Oct 2011 10:44:57 +0200
>> Cc: Juri Linkov <juri@jurta.org>, 9800@debbugs.gnu.org
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>>> Does lseek work on these files?
>> 
>> No.  The contents are completely dynamic, generated on-the-fly when
>> reading.
>> 
>>> Or we could treat those files as non-regular,
>> 
>> That is the only option.
> 
> Are all the files in "/proc" of this nature?  If so, we could consider
> all of the files in that directory non-regular; if that is all that's
> needed to visit /proc/foo files, insert-file-contents already has code
> to deal with non-regular files.
> 
> Paul, do you see any downsides to such heuristic?  We could make it a
> user option if the heuristic could sometimes backfire, I guess.

Best,


RY

bug#9800: Incomplete truncated file buffers from the /proc filesystem

[Arsen Arsenović via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

Hi,

I was just debugging this before I found the bug report.  The diagnosis
is right: st_size is wrong for proc files (and, I'd argue, for regular
files sometimes).  So, I agree with Paul.

Paul Eggert <eggert@cs.ucla.edu> writes:

> On 10/24/11 14:50, Richard Stallman wrote:
>> I think there was a reason for doing it this way.  Perhaps so as to
>> allocate the space before reading the file.
>
> Yes, that sounds right.  And in the typical case where the file is not
> growing, that allocates space efficiently.  If the file is growing, though,
> it's OK to allocate more space after discovering that the initial
> allocation was too small.

Right.  The best possible approach is, likely:

  fstat (fd, x, &st)
  bufsz = max (READ_BUF_SIZE, st.st_size)
  buf = malloc (bufsz)

  int ret = 0, readsz = 0;
  do
    {
      readsz += ret;
      if (readsz == bufsz && size isn't unreasonable)
        {
          /* value chosen arbitrarily.  */
          bufsz += min (16 * READ_BUF_SIZE, bufsz)
          buf = realloc (buf, bufsz)
        }
      errno = 0
      ret = read (fd, buf + readsz, bufsz - readsz)
    }
  while (ret > 0 || errno == EINTR);

... or such.  This approach is robust and general, and I suspect it'd
even work for named pipes.

st_size isn't a good enough indicator of size, and it can go out of date
before TOU, however, it's - no doubt - a useful hint in the 99% case.
Using st_size to figure out a base allocation size and extending
appropriately is a well known strategy, and it would be appropriate to
do so here.

Thanks in advance, have a great day.
-- 
Arsen Arsenović

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 381 bytes --]

bug#9800: Incomplete truncated file buffers from the /proc filesystem

[Paul Eggert]

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

On 2023-02-12 02:21, Arsen Arsenović wrote:
> ... or such.  This approach is robust and general, and I suspect it'd
> even work for named pipes.

Although indeed robust and general and it will work with named pipes in 
some cases, it still has a problem if the other side of the named pipe 
outputs data very slowly: Emacs will still seem to hang until you type C-g.

That being said, the approach is an improvement and it fixes the 
original bug report so I installed the attached and am boldly closing 
the bug report (we can reopen it if I'm wrong). The last patch in the 
attached series is the actual fix: the others are minor cleanups of this 
messy area, which I discovered while looking into the fix.

This patch does not address the abovementioned issue of named pipes, nor 
the issue of inserting very large files: the code should behave roughly 
the same as before in those two areas. These issues can be raised in 
separate bug reports if needed.

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
4 files contained unexpected results:
   src/lread-tests.log
   lisp/international/mule-tests.log
   lisp/emacs-lisp/map-tests.log
   lisp/emacs-lisp/bytecomp-tests.log

[-- Attachment #2: 0001-Improve-insert-file-contents-checking.patch --]
[-- Type: text/x-patch, Size: 2041 bytes --]

From 5284af27ee5250c631ff4ee2f3d8682f0c5df8bc Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Sun, 12 Feb 2023 17:30:46 -0800
Subject: [PATCH 1/5] Improve insert-file-contents checking

* src/fileio.c (Finsert_file_contents): Check BEG, END,
REPLACE for validity before launching into opening files etc.
---
 src/fileio.c | 29 ++++++++++++-----------------
 1 file changed, 12 insertions(+), 17 deletions(-)

diff --git a/src/fileio.c b/src/fileio.c
index c672e0f7baf..64337abdaef 100644
--- a/src/fileio.c
+++ b/src/fileio.c
@@ -3908,7 +3908,6 @@ because (1) it preserves some marker positions (in unchanged portions
   int fd;
   ptrdiff_t inserted = 0;
   ptrdiff_t how_much;
-  off_t beg_offset, end_offset;
   int unprocessed;
   specpdl_ref count = SPECPDL_INDEX ();
   Lisp_Object handler, val, insval, orig_filename, old_undo;
@@ -3970,6 +3969,17 @@ because (1) it preserves some marker positions (in unchanged portions
       goto handled;
     }
 
+  if (!NILP (visit))
+    {
+      if (!NILP (beg) || !NILP (end))
+	error ("Attempt to visit less than an entire file");
+      if (BEG < Z && NILP (replace))
+	error ("Cannot do file visiting in a non-empty buffer");
+    }
+
+  off_t beg_offset = !NILP (beg) ? file_offset (beg) : 0;
+  off_t end_offset = !NILP (end) ? file_offset (end) : -1;
+
   orig_filename = filename;
   filename = ENCODE_FILE (filename);
 
@@ -4030,22 +4040,7 @@ because (1) it preserves some marker positions (in unchanged portions
 		  build_string ("not a regular file"), orig_filename);
     }
 
-  if (!NILP (visit))
-    {
-      if (!NILP (beg) || !NILP (end))
-	error ("Attempt to visit less than an entire file");
-      if (BEG < Z && NILP (replace))
-	error ("Cannot do file visiting in a non-empty buffer");
-    }
-
-  if (!NILP (beg))
-    beg_offset = file_offset (beg);
-  else
-    beg_offset = 0;
-
-  if (!NILP (end))
-    end_offset = file_offset (end);
-  else
+  if (end_offset < 0)
     {
       if (!regular)
 	end_offset = TYPE_MAXIMUM (off_t);
-- 
2.37.2


[-- Attachment #3: 0002-Improve-insert-file-contents-on-non-regular-files.patch --]
[-- Type: text/x-patch, Size: 1521 bytes --]

From b0842671e750be08356425e2fc38251e7b08d5d7 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Sun, 12 Feb 2023 17:52:46 -0800
Subject: [PATCH 2/5] Improve insert-file-contents on non-regular files
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* src/fileio.c (Finsert_file_contents):
If the file is not a regular file, check REPLACE and VISIT
before doing further syscalls that won’t matter in this case.
---
 src/fileio.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/src/fileio.c b/src/fileio.c
index 64337abdaef..751b8ec573c 100644
--- a/src/fileio.c
+++ b/src/fileio.c
@@ -4022,7 +4022,6 @@ because (1) it preserves some marker positions (in unchanged portions
   if (!S_ISREG (st.st_mode))
     {
       regular = false;
-      seekable = lseek (fd, 0, SEEK_CUR) < 0;
 
       if (! NILP (visit))
         {
@@ -4030,14 +4029,15 @@ because (1) it preserves some marker positions (in unchanged portions
 	  goto notfound;
         }
 
+      if (!NILP (replace))
+	xsignal2 (Qfile_error,
+		  build_string ("not a regular file"), orig_filename);
+
+      seekable = lseek (fd, 0, SEEK_CUR) < 0;
       if (!NILP (beg) && !seekable)
 	xsignal2 (Qfile_error,
 		  build_string ("cannot use a start position in a non-seekable file/device"),
 		  orig_filename);
-
-      if (!NILP (replace))
-	xsignal2 (Qfile_error,
-		  build_string ("not a regular file"), orig_filename);
     }
 
   if (end_offset < 0)
-- 
2.37.2


[-- Attachment #4: 0003-Don-t-scan-text-twice-to-guess-coding-system.patch --]
[-- Type: text/x-patch, Size: 1195 bytes --]

From ccc092115172f15c9135771f90d0000f8bf21614 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Mon, 13 Feb 2023 08:51:45 -0800
Subject: [PATCH 3/5] =?UTF-8?q?Don=E2=80=99t=20scan=20text=20twice=20to=20?=
 =?UTF-8?q?guess=20coding=20system?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* src/fileio.c (Finsert_file_contents): If the file shrank
below 4 KiB, don’t read duplicate text into READ_BUF.
This also removes a use of SEEK_END, which Linux /proc
file systems do not support (not that we should get here
with /proc).
---
 src/fileio.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/fileio.c b/src/fileio.c
index 751b8ec573c..47177be0f4d 100644
--- a/src/fileio.c
+++ b/src/fileio.c
@@ -4119,7 +4119,7 @@ because (1) it preserves some marker positions (in unchanged portions
 		  if (nread == 1024)
 		    {
 		      int ntail;
-		      if (lseek (fd, - (1024 * 3), SEEK_END) < 0)
+		      if (lseek (fd, st.st_size - 1024 * 3, SEEK_CUR) < 0)
 			report_file_error ("Setting file position",
 					   orig_filename);
 		      ntail = emacs_read_quit (fd, read_buf + nread, 1024 * 3);
-- 
2.37.2


[-- Attachment #5: 0004-Fix-src-fileio.c-comment.patch --]
[-- Type: text/x-patch, Size: 1022 bytes --]

From bae5fa5d9a8ef8c41fbb3408eea441a2ee14d1db Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Mon, 13 Feb 2023 08:53:52 -0800
Subject: [PATCH 4/5] Fix src/fileio.c comment
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* src/fileio.c (Finsert_file_contents): Fix comment.
Since the code relies on st_size, it’s limited to
regular files, not to seekable files.
---
 src/fileio.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/fileio.c b/src/fileio.c
index 47177be0f4d..ee30db8b49b 100644
--- a/src/fileio.c
+++ b/src/fileio.c
@@ -4101,7 +4101,7 @@ because (1) it preserves some marker positions (in unchanged portions
       else
 	{
 	  /* Don't try looking inside a file for a coding system
-	     specification if it is not seekable.  */
+	     specification if it is not a regular file.  */
 	  if (regular && !NILP (Vset_auto_coding_function))
 	    {
 	      /* Find a coding system specified in the heading two
-- 
2.37.2


[-- Attachment #6: 0005-Fix-insert-file-contents-on-proc-files.patch --]
[-- Type: text/x-patch, Size: 4914 bytes --]

From b950b46f514989442fdd9937a0e96d53a3affa88 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Mon, 13 Feb 2023 12:32:11 -0800
Subject: [PATCH 5/5] Fix insert-file-contents on /proc files

This should fix Bug#9800 (2011-10-19).
* src/fileio.c (Finsert_file_contents):
Do not trust st_size even on regular files, as the file might
be a Linux /proc file, or it might be growing.
Instead, always read to EOF when END is nil.
---
 src/fileio.c | 57 +++++++++++++++++++++++-----------------------------
 1 file changed, 25 insertions(+), 32 deletions(-)

diff --git a/src/fileio.c b/src/fileio.c
index ee30db8b49b..b80f8d61de4 100644
--- a/src/fileio.c
+++ b/src/fileio.c
@@ -3907,7 +3907,6 @@ because (1) it preserves some marker positions (in unchanged portions
   struct timespec mtime;
   int fd;
   ptrdiff_t inserted = 0;
-  ptrdiff_t how_much;
   int unprocessed;
   specpdl_ref count = SPECPDL_INDEX ();
   Lisp_Object handler, val, insval, orig_filename, old_undo;
@@ -3920,7 +3919,8 @@ because (1) it preserves some marker positions (in unchanged portions
   bool replace_handled = false;
   bool set_coding_system = false;
   Lisp_Object coding_system;
-  bool read_quit = false;
+  /* Negative if read error, 0 if OK so far, positive if quit.  */
+  ptrdiff_t read_quit = 0;
   /* If the undo log only contains the insertion, there's no point
      keeping it.  It's typically when we first fill a file-buffer.  */
   bool empty_undo_list_p
@@ -4404,7 +4404,7 @@ because (1) it preserves some marker positions (in unchanged portions
       ptrdiff_t bufpos;
       unsigned char *decoded;
       ptrdiff_t temp;
-      ptrdiff_t this = 0;
+      ptrdiff_t this;
       specpdl_ref this_count = SPECPDL_INDEX ();
       bool multibyte
 	= ! NILP (BVAR (current_buffer, enable_multibyte_characters));
@@ -4580,8 +4580,12 @@ because (1) it preserves some marker positions (in unchanged portions
     }
 
   move_gap_both (PT, PT_BYTE);
-  if (GAP_SIZE < total)
-    make_gap (total - GAP_SIZE);
+
+  /* Ensure the gap is at least one byte larger than needed for the
+     estimated file size, so that in the usual case we read to EOF
+     without reallocating.  */
+  if (GAP_SIZE <= total)
+    make_gap (total - GAP_SIZE + 1);
 
   if (beg_offset != 0 || !NILP (replace))
     {
@@ -4589,12 +4593,6 @@ because (1) it preserves some marker positions (in unchanged portions
 	report_file_error ("Setting file position", orig_filename);
     }
 
-  /* In the following loop, HOW_MUCH contains the total bytes read so
-     far for a regular file, and not changed for a special file.  But,
-     before exiting the loop, it is set to a negative value if I/O
-     error occurs.  */
-  how_much = 0;
-
   /* Total bytes inserted.  */
   inserted = 0;
 
@@ -4603,23 +4601,26 @@ because (1) it preserves some marker positions (in unchanged portions
   {
     ptrdiff_t gap_size = GAP_SIZE;
 
-    while (how_much < total)
+    while (NILP (end) || inserted < total)
       {
-	/* `try' is reserved in some compilers (Microsoft C).  */
-	ptrdiff_t trytry = min (total - how_much, READ_BUF_SIZE);
 	ptrdiff_t this;
 
+	if (gap_size == 0)
+	  {
+	    /* The size estimate was wrong.  Make the gap 50% larger.  */
+	    make_gap (GAP_SIZE >> 1);
+	    gap_size = GAP_SIZE - inserted;
+	  }
+
+	/* 'try' is reserved in some compilers (Microsoft C).  */
+	ptrdiff_t trytry = min (gap_size, READ_BUF_SIZE);
+	if (!NILP (end))
+	  trytry = min (trytry, total - inserted);
+
 	if (!seekable && NILP (end))
 	  {
 	    Lisp_Object nbytes;
 
-	    /* Maybe make more room.  */
-	    if (gap_size < trytry)
-	      {
-		make_gap (trytry - gap_size);
-		gap_size = GAP_SIZE - inserted;
-	      }
-
 	    /* Read from the file, capturing `quit'.  When an
 	       error occurs, end the loop, and arrange for a quit
 	       to be signaled after decoding the text we read.  */
@@ -4630,7 +4631,7 @@ because (1) it preserves some marker positions (in unchanged portions
 
 	    if (NILP (nbytes))
 	      {
-		read_quit = true;
+		read_quit = 1;
 		break;
 	      }
 
@@ -4649,19 +4650,11 @@ because (1) it preserves some marker positions (in unchanged portions
 
 	if (this <= 0)
 	  {
-	    how_much = this;
+	    read_quit = this;
 	    break;
 	  }
 
 	gap_size -= this;
-
-	/* For a regular file, where TOTAL is the real size,
-	   count HOW_MUCH to compare with it.
-	   For a special file, where TOTAL is just a buffer size,
-	   so don't bother counting in HOW_MUCH.
-	   (INSERTED is where we count the number of characters inserted.)  */
-	if (seekable || !NILP (end))
-	  how_much += this;
 	inserted += this;
       }
   }
@@ -4682,7 +4675,7 @@ because (1) it preserves some marker positions (in unchanged portions
   emacs_close (fd);
   clear_unwind_protect (fd_index);
 
-  if (how_much < 0)
+  if (read_quit < 0)
     report_file_error ("Read error", orig_filename);
 
  notfound:
-- 
2.37.2

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

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

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.