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

[charles@aurox.ch (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.