GNU bug report logs - #37408
27.0.50; list-processes can hang

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 37408 in the body.
You can then email your comments to 37408 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: Lars Ingebrigtsen <larsi <at> gnus.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 27.0.50; list-processes can hang
Date: Sun, 15 Sep 2019 14:06:57 +0200

I just tried to kill Emacs, but it seems to hang indefinitely, so I
`C-g' and got this backtrace:

Debugger entered--Lisp error: (quit)
  process-contact(#<process raw.githubusercontent.com<3>> t)
  list-processes--refresh()
  list-processes(t)
  save-buffers-kill-emacs(nil)
  save-buffers-kill-terminal(nil)
  funcall-interactively(save-buffers-kill-terminal nil)
  call-interactively(save-buffers-kill-terminal nil nil)
  command-execute(save-buffers-kill-terminal)

So it hangs while trying to get info to query the user about killing
some processes.

Does this seem familiar to anybody?  Calling `process-contact' on this
process seems to reliably infloop.



In GNU Emacs 27.0.50 (build 44, x86_64-pc-linux-gnu, GTK+ Version 3.22.11)
 of 2019-09-04 built on marnie
Repository revision: 4c3a40a9b7b8b953d7882942d44373ccd8f7a3cd
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.11902000
System Description: Debian GNU/Linux 9 (stretch)


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

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: 37408 <at> debbugs.gnu.org
Subject: Re: bug#37408: 27.0.50; list-processes can hang
Date: Sun, 15 Sep 2019 14:25:48 +0200

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Does this seem familiar to anybody?  Calling `process-contact' on this
> process seems to reliably infloop.

DEFUN ("process-contact", Fprocess_contact, Sprocess_contact,
       1, 2, 0,

[...]

If PROCESS is a non-blocking network process that hasn't been fully
set up yet, this function will block until socket setup has completed.  */)

[...]

  if (NETCONN_P (process))
    wait_for_socket_fds (process, "process-contact");

So this function is advertised as blocking if called on an incompletely
set-up connection, which seems to be the case here.  And it's never
going to be completed, which can happen...

I'm not sure what the right fix here would be.

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

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: 37408 <at> debbugs.gnu.org
Subject: Re: bug#37408: 27.0.50; list-processes can hang
Date: Sun, 15 Sep 2019 14:38:12 +0200

OK, here's the relevant data in list-processes:

    p = #<process raw.githubusercontent.com<3>>
    type = network
    name = "raw.githubusercontent.com<3>"
    status = "connect"

The problem here is that when a process in the status "connect", it may
be in two distinctly different states: It may still be doing the DNS
lookup (which may fail for some reason or other), and it'll never
progress from that state.  This is usually cleaned up by whatever the
caller is, but if the user has `C-g' somewhere, the process may linger
in that condition.

And if it's in that state, then the rest of Fprocess_contact can't be
done, because the data isn't present.

But there's another "connect" state -- after the DNS has been completed,
and we're doing a TCP connect.  In that case, the rest of the function
is fine to do, because we've filled in the peer etc.

`list-processes' could avoid calling Fprocess_contact if the status is
"connect", but that would lose info on processes in the second
sub-state.

So I don't know...  Anybody got an idea?  Introducing a new state
("pre-connect") would probably break a lot of stuff; adding a timeout
parameter and then return nil if it's exceeded would be possible; making
list-processes not display the details for all "connect" processes is
possible.  It would look like this:

raw.githubus... --      connect  *http raw.githubuserc... --           Main         (connecting)

Patch for reference.

diff --git a/lisp/simple.el b/lisp/simple.el
index 358b6a4f20..5812111109 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -4107,30 +4107,32 @@ list-processes--refresh
 		    (t "--")))
 		  (cmd
 		   (if (memq type '(network serial))
-		       (let ((contact (process-contact p t)))
-			 (if (eq type 'network)
-			     (format "(%s %s)"
-				     (if (plist-get contact :type)
-					 "datagram"
-				       "network")
-				     (if (plist-get contact :server)
-					 (format
-                                          "server on %s"
-					  (if (plist-get contact :host)
-                                              (format "%s:%s"
-						      (plist-get contact :host)
-                                                      (plist-get
-                                                       contact :service))
-					    (plist-get contact :local)))
-				       (format "connection to %s:%s"
-					       (plist-get contact :host)
-					       (plist-get contact :service))))
-			   (format "(serial port %s%s)"
-				   (or (plist-get contact :port) "?")
-				   (let ((speed (plist-get contact :speed)))
-				     (if speed
-					 (format " at %s b/s" speed)
-				       "")))))
+                       (if (equal status "connect")
+                           "(connecting)"
+		         (let ((contact (process-contact p t)))
+			   (if (eq type 'network)
+			       (format "(%s %s)"
+				       (if (plist-get contact :type)
+					   "datagram"
+				         "network")
+				       (if (plist-get contact :server)
+					   (format
+                                            "server on %s"
+					    (if (plist-get contact :host)
+                                                (format "%s:%s"
+						        (plist-get contact :host)
+                                                        (plist-get
+                                                         contact :service))
+					      (plist-get contact :local)))
+				         (format "connection to %s:%s"
+					         (plist-get contact :host)
+					         (plist-get contact :service))))
+			     (format "(serial port %s%s)"
+				     (or (plist-get contact :port) "?")
+				     (let ((speed (plist-get contact :speed)))
+				       (if speed
+					   (format " at %s b/s" speed)
+				         ""))))))
 		     (mapconcat 'identity (process-command p) " "))))
 	     (push (list p (vector name pid status buf-label tty thread cmd))
 		   tabulated-list-entries)))))


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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 37408 <at> debbugs.gnu.org
Subject: Re: bug#37408: 27.0.50; list-processes can hang
Date: Sun, 15 Sep 2019 17:54:57 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Sun, 15 Sep 2019 14:25:48 +0200
> 
> If PROCESS is a non-blocking network process that hasn't been fully
> set up yet, this function will block until socket setup has completed.  */)
> 
> [...]
> 
>   if (NETCONN_P (process))
>     wait_for_socket_fds (process, "process-contact");
> 
> So this function is advertised as blocking if called on an incompletely
> set-up connection, which seems to be the case here.  And it's never
> going to be completed, which can happen...
> 
> I'm not sure what the right fix here would be.

Wait with a timeout? check for C-g while waiting?

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 37408 <at> debbugs.gnu.org
Subject: Re: bug#37408: 27.0.50; list-processes can hang
Date: Mon, 16 Sep 2019 15:20:50 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> Wait with a timeout? check for C-g while waiting?

I don't know what a reasonable timeout would be that would cover all
cases where this function may be used, so passing in a timeout might be
the solution.  `list-processes', for instance, don't need the
information for anything other than (minor) display purposes, so it
could pass in zero as a "don't wait" would make sense there.

Checking for `C-g' (and then returning nil if given) would also be a
possibility, but would be less useful for non-interactive use...

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

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 37408 <at> debbugs.gnu.org
Subject: Re: bug#37408: 27.0.50; list-processes can hang
Date: Fri, 20 Sep 2019 20:20:11 +0200

I've now just added an extra parameter to make `process-contact' not
block in these instances, and altered list-processes to use that
parameter.  

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