GNU bug report logs - #6074
accept-process-output on listening sockets cause non-interruptible infloop

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 6074 in the body.
You can then email your comments to 6074 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Helmut Eller <eller.helmut <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.0.50; accept-process-output on listening sockets not incorruptible
Date: Sun, 02 May 2010 00:15:53 +0200

With this code Emacs seems to be stuck in an endless loop and is not
incorruptible with C-g:

(let ((proc (make-network-process :name "foo" :server t :noquery t 
				  :family 'local :service "/tmp/foo.socket")))
  (accept-process-output proc))

Message #14 received at 6074 <at> debbugs.gnu.org (full text, mbox):

From: Pip Cet <pipcet <at> gmail.com>
To: 6074 <at> debbugs.gnu.org
Subject: accept-process-output on listening sockets cause non-interruptible
 infloop
Date: Mon, 22 Jul 2019 03:52:33 +0000

[Message part 1 (text/plain, inline)]

> With this code Emacs seems to be stuck in an endless loop and is not
> incorruptible with C-g:

> (let ((proc (make-network-process :name "foo" :server t :noquery t
>  :family 'local :service "/tmp/foo.socket")))
>   (accept-process-output proc))

On Linux, the problem appears to be that we don't abort this infloop
in process.c if a read () returns EINVAL:

          while (true)
        {
          int nread = read_process_output (proc, wait_proc->infd);
          if (nread < 0)
            {
              if (errno == EIO || would_block (errno))
            break;
            }
          else
            {
              if (got_some_output < nread)
            got_some_output = nread;
              if (nread == 0)
            break;
              read_some_bytes = true;
            }
        }

That seems problematic to me, since we might get non-EIO errors for
other reasons. I'm attaching a patch that appears to fix the issue.

[0001-Don-t-retry-reading-after-receiving-EINVAL-bug-6074.patch (text/x-patch, attachment)]

Message #17 received at 6074 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pip Cet <pipcet <at> gmail.com>
Cc: 6074 <at> debbugs.gnu.org
Subject: Re: bug#6074: accept-process-output on listening sockets cause
 non-interruptible infloop
Date: Mon, 22 Jul 2019 17:26:29 +0300

> From: Pip Cet <pipcet <at> gmail.com>
> Date: Mon, 22 Jul 2019 03:52:33 +0000
> 
> diff --git a/src/process.c b/src/process.c
> index abadabe77e..1311409274 100644
> --- a/src/process.c
> +++ b/src/process.c
> @@ -5277,7 +5277,9 @@ wait_reading_process_output (intmax_t time_limit, int nsecs, int read_kbd,
>  		  int nread = read_process_output (proc, wait_proc->infd);
>  		  if (nread < 0)
>  		    {
> -		      if (errno == EIO || would_block (errno))
> +		      if (errno == EINTR)
> +			continue;
> +		      else
>  			break;
>  		    }
>  		  else

Isn't it better to simply call rarely_quit inside the loop?

Message #20 received at 6074 <at> debbugs.gnu.org (full text, mbox):

From: Pip Cet <pipcet <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 6074 <at> debbugs.gnu.org
Subject: Re: bug#6074: accept-process-output on listening sockets cause
 non-interruptible infloop
Date: Mon, 22 Jul 2019 17:45:18 +0000

[Message part 1 (text/plain, inline)]

On Mon, Jul 22, 2019 at 2:26 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> > From: Pip Cet <pipcet <at> gmail.com>
> > Date: Mon, 22 Jul 2019 03:52:33 +0000
> >
> > diff --git a/src/process.c b/src/process.c
> > index abadabe77e..1311409274 100644
> > --- a/src/process.c
> > +++ b/src/process.c
> > @@ -5277,7 +5277,9 @@ wait_reading_process_output (intmax_t time_limit, int nsecs, int read_kbd,
> >                 int nread = read_process_output (proc, wait_proc->infd);
> >                 if (nread < 0)
> >                   {
> > -                   if (errno == EIO || would_block (errno))
> > +                   if (errno == EINTR)
> > +                     continue;
> > +                   else
> >                       break;
> >                   }
> >                 else
>
> Isn't it better to simply call rarely_quit inside the loop?

Why would we try again after receiving EINVAL? I believe the right
behavior is to return immediately in this case, just as we do for EIO.

However, we should probably call rarely_quit inside the loop, anyway,
to catch the case of a kernel bug keeping us busy with EINTRs. How's
this?

[0001-Don-t-retry-reading-after-receiving-EINVAL-bug-6074.patch (text/x-patch, attachment)]

Message #23 received at 6074 <at> debbugs.gnu.org (full text, mbox):

From: Richard Stallman <rms <at> gnu.org>
To: Pip Cet <pipcet <at> gmail.com>
Cc: 6074 <at> debbugs.gnu.org
Subject: Re: bug#6074: accept-process-output on listening sockets cause
 non-interruptible infloop
Date: Mon, 22 Jul 2019 22:46:06 -0400

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > On Linux, the problem appears to be that

Those words lead me to think that you're running GNU Emacs as
part of the GNU operating system -- a version with Linx as the kernel.
One of the obstacles that we GNU developers have to face
is that people that use GNU don't know it is GNU.  They think
the system is "Linux".

Thanks for reporting a bug in one part of the GNU system.  While
you're at it, could you please call the system "GNU/Linux", so as to
help correct the misinformation of what it is, where it comes from,
and why we developed it?

See https://gnu.org/gnu/linux-and-gnu.html and
https://gnu.org/gnu/gnu-linux-faq.html, plus the history in
https://gnu.org/gnu/the-gnu-project.html.


-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Message #26 received at 6074 <at> debbugs.gnu.org (full text, mbox):

From: Pip Cet <pipcet <at> gmail.com>
To: rms <at> gnu.org
Cc: 6074 <at> debbugs.gnu.org
Subject: Re: bug#6074: accept-process-output on listening sockets cause
 non-interruptible infloop
Date: Tue, 23 Jul 2019 14:31:16 +0000

On Tue, Jul 23, 2019 at 2:46 AM Richard Stallman <rms <at> gnu.org> wrote:
>   > On Linux, the problem appears to be that
>
> Those words lead me to think that you're running GNU Emacs as
> part of the GNU operating system -- a version with Linx as the kernel.

I am, indeed, but in this particular case, it is the Linux kernel
doing something problematic: returning -EINVAL, which glibc merely
stores in errno.  But I agree it would have been more accurate to say
something like "On this GNU/Linux system, the problem appears to be
that the Linux kernel..."

> Thanks for reporting a bug in one part of the GNU system.  While

(I didn't report it, I merely reproduced a very old bug report and
suggested a fix.)

> you're at it, could you please call the system "GNU/Linux", so as to
> help correct the misinformation of what it is, where it comes from,
> and why we developed it?

Thanks for taking the time to remind me of that.

Message #29 received at 6074 <at> debbugs.gnu.org (full text, mbox):

From: Richard Stallman <rms <at> gnu.org>
To: Pip Cet <pipcet <at> gmail.com>
Cc: 6074 <at> debbugs.gnu.org
Subject: Re: bug#6074: accept-process-output on listening sockets cause
 non-interruptible infloop
Date: Wed, 24 Jul 2019 23:08:54 -0400

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

Happy hacking!

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Message #32 received at 6074 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Pip Cet <pipcet <at> gmail.com>
Cc: 6074 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#6074: accept-process-output on listening sockets cause
 non-interruptible infloop
Date: Mon, 14 Sep 2020 15:21:11 +0200

Pip Cet <pipcet <at> gmail.com> writes:

> Why would we try again after receiving EINVAL? I believe the right
> behavior is to return immediately in this case, just as we do for EIO.
>
> However, we should probably call rarely_quit inside the loop, anyway,
> to catch the case of a kernel bug keeping us busy with EINTRs. How's
> this?

[...]

>  	    {
> +	      unsigned int count = 0;
>  	      XSETPROCESS (proc, wait_proc);
>  
>  	      while (true)
>  		{
>  		  int nread = read_process_output (proc, wait_proc->infd);
> +		  rarely_quit (++count);
>  		  if (nread < 0)
>  		    {
> -		      if (errno == EIO || would_block (errno))
> +		      if (errno != EINTR)
>  			break;
>  		    }
>  		  else

There was no followup on this patch at the time (except Richard chiding
you for using forbidden terminology), but I tried the patch now, and it
seems to fix the issue, so I've applied it to the trunk now.

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.