[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#28544: 26.0.50; emacs will consume 100% cpu after gdb debugee exits
From: |
Charles A. Roelli |
Subject: |
bug#28544: 26.0.50; emacs will consume 100% cpu after gdb debugee exits |
Date: |
Sun, 26 Nov 2017 15:17:43 +0100 |
> 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.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- bug#28544: 26.0.50; emacs will consume 100% cpu after gdb debugee exits,
Charles A. Roelli <=