unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#37408: 27.0.50; list-processes can hang
@ 2019-09-15 12:06 Lars Ingebrigtsen
  2019-09-15 12:25 ` Lars Ingebrigtsen
  2019-09-15 12:38 ` Lars Ingebrigtsen
  0 siblings, 2 replies; 6+ messages in thread
From: Lars Ingebrigtsen @ 2019-09-15 12:06 UTC (permalink / raw)
  To: 37408


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






^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#37408: 27.0.50; list-processes can hang
  2019-09-15 12:06 bug#37408: 27.0.50; list-processes can hang Lars Ingebrigtsen
@ 2019-09-15 12:25 ` Lars Ingebrigtsen
  2019-09-15 14:54   ` Eli Zaretskii
  2019-09-15 12:38 ` Lars Ingebrigtsen
  1 sibling, 1 reply; 6+ messages in thread
From: Lars Ingebrigtsen @ 2019-09-15 12:25 UTC (permalink / raw)
  To: 37408

Lars Ingebrigtsen <larsi@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





^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#37408: 27.0.50; list-processes can hang
  2019-09-15 12:06 bug#37408: 27.0.50; list-processes can hang Lars Ingebrigtsen
  2019-09-15 12:25 ` Lars Ingebrigtsen
@ 2019-09-15 12:38 ` Lars Ingebrigtsen
  1 sibling, 0 replies; 6+ messages in thread
From: Lars Ingebrigtsen @ 2019-09-15 12:38 UTC (permalink / raw)
  To: 37408

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






^ permalink raw reply related	[flat|nested] 6+ messages in thread

* bug#37408: 27.0.50; list-processes can hang
  2019-09-15 12:25 ` Lars Ingebrigtsen
@ 2019-09-15 14:54   ` Eli Zaretskii
  2019-09-16 13:20     ` Lars Ingebrigtsen
  0 siblings, 1 reply; 6+ messages in thread
From: Eli Zaretskii @ 2019-09-15 14:54 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 37408

> From: Lars Ingebrigtsen <larsi@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?





^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#37408: 27.0.50; list-processes can hang
  2019-09-15 14:54   ` Eli Zaretskii
@ 2019-09-16 13:20     ` Lars Ingebrigtsen
  2019-09-20 18:20       ` Lars Ingebrigtsen
  0 siblings, 1 reply; 6+ messages in thread
From: Lars Ingebrigtsen @ 2019-09-16 13:20 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 37408

Eli Zaretskii <eliz@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





^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#37408: 27.0.50; list-processes can hang
  2019-09-16 13:20     ` Lars Ingebrigtsen
@ 2019-09-20 18:20       ` Lars Ingebrigtsen
  0 siblings, 0 replies; 6+ messages in thread
From: Lars Ingebrigtsen @ 2019-09-20 18:20 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 37408

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






^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2019-09-20 18:20 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-09-15 12:06 bug#37408: 27.0.50; list-processes can hang Lars Ingebrigtsen
2019-09-15 12:25 ` Lars Ingebrigtsen
2019-09-15 14:54   ` Eli Zaretskii
2019-09-16 13:20     ` Lars Ingebrigtsen
2019-09-20 18:20       ` Lars Ingebrigtsen
2019-09-15 12:38 ` Lars Ingebrigtsen

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).