bug#28544: 26.0.50; emacs will consume 100% cpu after gdb debugee exits

bug#28544: 26.0.50; emacs will consume 100% cpu after gdb debugee exits

[Sung Ho Kim]

First time using the bug report system, so apologies in advance if the
report feels muddled.

The procedure I had used is as follows:
1) open emacs [-Q] [-nw]
   N.B. the option flags -Q -nw do not make any difference in the
   behavior described.
2) run gdb using M-x gdb ( I have tested gdb 7.12 and 8.0, 8.0.1 and
   even earlier versions but gdb version do not seem to make any difference)
3) open any executable binary for debugging.
4) continue, step, next or run until binary in step (3) finishes
   execution and exits (whether it exits normally or abnormally does not
   make a difference)
5) open top and watch emacs cpu usage.

What I have noticed with a little bit of debugging and looking at the
emacs source code is that in process.c in about line 5660 (thankfully
process.c receives very little changes recently so the line number
should be approximately accurate) you see the following code:
-------------------------------------------------------------------
	      /* If we can detect process termination, don't consider the
		 process gone just because its pipe is closed.  */
	      else if (nread == 0 && !NETCONN_P (proc) && !SERIALCONN_P (proc)
		       && !PIPECONN_P (proc))
-------------------------------------------------------------------
This if clause becomes true when the debugee exits in Mac OS Sierra
(10.12.6, BuildVersion 16G29, Darwin Kernel Version 16.7.0) and since
nothing is done about the read file descriptor (proc's infd, outfd,
channel) this results in an infinite loop where thread_select keeps
returning nfds = 1 but the subsequent read operation will not return an
error (i.e. nread will never be < 0) and nread will always be 0.  I feel
this infinite loop is the cause of the 100% cpu usage behavior.

To test this theory, I added the same code used in the
(nread == -1 && errno == EIO) condition to the
(nread == 0 && !NETCONN_P (proc) && !SERIALCONN_P (proc) && !PIPECONN_P(proc))
condition to remove the target file descriptor when this condition is
encountered as such:

	      else if (nread == 0 && !NETCONN_P (proc) && !SERIALCONN_P (proc)
		       && !PIPECONN_P (proc))
#ifdef DARWIN_OS
		{
		  struct Lisp_Process *p = XPROCESS (proc);

		  /* Clear the descriptor now, so we only raise the
		     signal once.  */
		  delete_read_fd (channel);

		  if (p->pid == -2)
		    {
		      /* If the EIO occurs on a pty, the SIGCHLD handler's
			 waitpid call will not find the process object to
			 delete.  Do it here.  */
		      p->tick = ++process_tick;
		      pset_status (p, Qfailed);
		    }
		}
#else
                ;
#endif /* DARWIN_OS */

after rebuilding with the aforementioned change, the 100% cpu usage
disappears.  I have refrained from offering a patch because I am not
fully knowledgeable with the code and its possible side effects.

Thank you for your patience and your great work developing this great OS.


In GNU Emacs 26.0.50 (build 2, x86_64-apple-darwin16.7.0)
 of 2017-09-20 built on dana.local
Repository revision: bc511a64f6da9ab51acc7c8865e80c4a4cb655c2
Recent messages:
applying putty GNU screen fixes.
Reusing Dired buffers is now ON
Turning on magit-auto-revert-mode...done
ad-handle-definition: ‘compilation-start’ got redefined
For information about GNU Emacs and the GNU system, type C-h C-a.

Configured using:
 'configure --prefix=/opt/local/emacs-git --without-makeinfo
 --without-ns --without-pop --without-mailutils'

Configured features:
DBUS NOTIFY ACL GNUTLS LIBXML2 ZLIB

Important settings:
  value of $LC_ALL: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Fundamental

Minor modes in effect:
  diff-auto-refine-mode: t
  magit-auto-revert-mode: t
  global-git-commit-mode: t
  async-bytecomp-package-mode: t
  shell-dirtrack-mode: t
  bury-successful-compilation: t
  global-auto-complete-mode: t
  cl-old-struct-compat-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
~/.emacs.d/lisp/expand-region-core hides /Users/sk68/.emacs.d/elpa/expand-region-0.11.0/expand-region-core
~/.emacs.d/lisp/linum hides /opt/local/emacs-git/share/emacs/26.0.50/lisp/linum

Features:
(shadow sort mail-extr emacsbug sendmail term/xterm xterm flymake
flymake-proc compile flymake-ui display-line-numbers elec-pair
magit-obsolete magit-blame magit-stash magit-bisect magit-remote
magit-commit magit-sequence magit-notes magit-worktree magit-branch
magit-files magit-refs magit-status magit magit-repos magit-apply
magit-wip magit-log magit-diff smerge-mode diff-mode magit-core
magit-autorevert autorevert filenotify magit-process magit-margin
magit-mode magit-git magit-section magit-popup git-commit magit-utils
crm log-edit message subr-x puny rfc822 mml mml-sec epa epg gnus-util
rmail rmail-loaddefs time-date mm-decode mm-bodies mm-encode mail-parse
rfc2231 rfc2047 rfc2045 mm-util ietf-drums mail-prsvr mailabbrev
mail-utils gmm-utils mailheader pcvs-util add-log with-editor cl-extra
async-bytecomp async shell pcomplete comint ansi-color ring server dash
help-mode dired+ image-dired image-mode format-spec image-file image
dired-x dired-aux dired dired-loaddefs cl findheader
compilation-window-helper bury-successful-compilation advice
auto-complete-config auto-complete popup ztree ztree-diff
ztree-diff-model ztree-dir easy-mmode ztree-view edmacro kmacro
ztree-util jison-mode bison-mode derived cc-mode cc-fonts cc-guess
cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs regexp-opt
finder-inf info tool-bar package easymenu epg-config url-handlers
url-parse auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs
password-cache url-vars seq byte-opt gv bytecomp byte-compile cconv
cl-loaddefs cl-lib mule-util tooltip eldoc electric uniquify ediff-hook
vc-hooks lisp-float-type tabulated-list replace newcomment text-mode
elisp-mode lisp-mode prog-mode register page menu-bar rfn-eshadow
isearch timer select mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite charscript charprop case-table epa-hook jka-cmpr-hook
help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote dbusbind kqueue multi-tty make-network-process emacs)

Memory information:
((conses 16 267423 9498)
 (symbols 48 33034 2)
 (miscs 40 79 97)
 (strings 32 73135 3249)
 (string-bytes 1 2304657)
 (vectors 16 29273)
 (vector-slots 8 620415 7189)
 (floats 8 124 327)
 (intervals 56 240 0)
 (buffers 992 12))

bug#28544: 26.0.50; emacs will consume 100% cpu after gdb debugee exits

[Charles A. Roelli]

> From: Sung Ho Kim <sk6875@gmail.com>
> Date: Wed, 20 Sep 2017 12:03:37 +0900
> 
> First time using the bug report system, so apologies in advance if the
> report feels muddled.
> 
> The procedure I had used is as follows:
> 1) open emacs [-Q] [-nw]
>    N.B. the option flags -Q -nw do not make any difference in the
>    behavior described.
> 2) run gdb using M-x gdb ( I have tested gdb 7.12 and 8.0, 8.0.1 and
>    even earlier versions but gdb version do not seem to make any difference)
> 3) open any executable binary for debugging.
> 4) continue, step, next or run until binary in step (3) finishes
>    execution and exits (whether it exits normally or abnormally does not
>    make a difference)
> 5) open top and watch emacs cpu usage.
> 
> What I have noticed with a little bit of debugging and looking at the
> emacs source code is that in process.c in about line 5660 (thankfully
> process.c receives very little changes recently so the line number
> should be approximately accurate) you see the following code:
> -------------------------------------------------------------------
> 	      /* If we can detect process termination, don't consider the
> 		 process gone just because its pipe is closed.  */
> 	      else if (nread == 0 && !NETCONN_P (proc) && !SERIALCONN_P (proc)
> 		       && !PIPECONN_P (proc))
> -------------------------------------------------------------------
> This if clause becomes true when the debugee exits in Mac OS Sierra
> (10.12.6, BuildVersion 16G29, Darwin Kernel Version 16.7.0) and since
> nothing is done about the read file descriptor (proc's infd, outfd,
> channel) this results in an infinite loop where thread_select keeps
> returning nfds = 1 but the subsequent read operation will not return an
> error (i.e. nread will never be < 0) and nread will always be 0.  I feel
> this infinite loop is the cause of the 100% cpu usage behavior.
> 
> To test this theory, I added the same code used in the
> (nread == -1 && errno == EIO) condition to the
> (nread == 0 && !NETCONN_P (proc) && !SERIALCONN_P (proc) && !PIPECONN_P(proc))
> condition to remove the target file descriptor when this condition is
> encountered as such:
> 
> 	      else if (nread == 0 && !NETCONN_P (proc) && !SERIALCONN_P (proc)
> 		       && !PIPECONN_P (proc))
> #ifdef DARWIN_OS
> 		{
> 		  struct Lisp_Process *p = XPROCESS (proc);
> 
> 		  /* Clear the descriptor now, so we only raise the
> 		     signal once.  */
> 		  delete_read_fd (channel);
> 
> 		  if (p->pid == -2)
> 		    {
> 		      /* If the EIO occurs on a pty, the SIGCHLD handler's
> 			 waitpid call will not find the process object to
> 			 delete.  Do it here.  */
> 		      p->tick = ++process_tick;
> 		      pset_status (p, Qfailed);
> 		    }
> 		}
> #else
>                 ;
> #endif /* DARWIN_OS */
> 
> after rebuilding with the aforementioned change, the 100% cpu usage
> disappears.  I have refrained from offering a patch because I am not
> fully knowledgeable with the code and its possible side effects.
> 
> Thank you for your patience and your great work developing this great OS.
> 
> 
> In GNU Emacs 26.0.50 (build 2, x86_64-apple-darwin16.7.0)
>  of 2017-09-20 built on dana.local

Thanks a lot for investigating this problem.  It also happens on macOS
10.6, and your change fixes it.  Not knowing much about this part of
Emacs myself, I hope somebody can review your change soon.

bug#28544: 26.0.50; emacs will consume 100% cpu after gdb debugee exits

[Lars Ingebrigtsen]

Sung Ho Kim <sk6875@gmail.com> writes:

> after rebuilding with the aforementioned change, the 100% cpu usage
> disappears.  I have refrained from offering a patch because I am not
> fully knowledgeable with the code and its possible side effects.

Well, that's unfortunate, because without a patch it's difficult to
interpret just what it is you're proposing.

If I piece together the code correctly, you're saying the following
patch fixes the problem on Macos?

diff --git a/src/process.c b/src/process.c
index 15634e4a8b..740891983e 100644
--- a/src/process.c
+++ b/src/process.c
@@ -5821,7 +5821,9 @@ wait_reading_process_output (intmax_t time_limit, int nsecs, int read_kbd,
 		 EIO, just continue, because the child process has
 		 exited and should clean itself up soon (e.g. when we
 		 get a SIGCHLD).  */
-	      else if (nread == -1 && errno == EIO)
+ 	      else if (nread == 0 && !NETCONN_P (proc) && !SERIALCONN_P (proc)
+ 		       && !PIPECONN_P (proc))
+#ifdef DARWIN_OS
 		{
 		  struct Lisp_Process *p = XPROCESS (proc);
 
@@ -5838,6 +5840,9 @@ wait_reading_process_output (intmax_t time_limit, int nsecs, int read_kbd,
 		      pset_status (p, Qfailed);
 		    }
 		}
+#else
+	      ;
+#endif
 #endif /* HAVE_PTYS */
 	      /* If we can detect process termination, don't consider the
 		 process gone just because its pipe is closed.  */


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

bug#28544: [macOS] emacs will consume 100% cpu after gdb debugee exits

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Well, that's unfortunate, because without a patch it's difficult to
> interpret just what it is you're proposing.
>
> If I piece together the code correctly, you're saying the following
> patch fixes the problem on Macos?

This was months ago, and there was no response, so it seems unlikely
that there'll be further progress here, and I'm closing this bug report.
If further progress can be made, please respond to the debbugs address
and we'll reopen.

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