From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: charles@aurox.ch (Charles A. Roelli) Newsgroups: gmane.emacs.bugs Subject: bug#28544: 26.0.50; emacs will consume 100% cpu after gdb debugee exits Date: Sun, 26 Nov 2017 15:17:43 +0100 Message-ID: References: NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1511705837 18318 195.159.176.226 (26 Nov 2017 14:17:17 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 26 Nov 2017 14:17:17 +0000 (UTC) Cc: 28544@debbugs.gnu.org To: Sung Ho Kim Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Nov 26 15:17:12 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eIxk7-00046X-6Q for geb-bug-gnu-emacs@m.gmane.org; Sun, 26 Nov 2017 15:17:11 +0100 Original-Received: from localhost ([::1]:56857 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eIxkB-0004qp-48 for geb-bug-gnu-emacs@m.gmane.org; Sun, 26 Nov 2017 09:17:15 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39210) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eIxk4-0004qj-0K for bug-gnu-emacs@gnu.org; Sun, 26 Nov 2017 09:17:09 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eIxjz-0005wt-1H for bug-gnu-emacs@gnu.org; Sun, 26 Nov 2017 09:17:07 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:50010) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eIxjy-0005wj-S7 for bug-gnu-emacs@gnu.org; Sun, 26 Nov 2017 09:17:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1eIxjy-00018k-HG for bug-gnu-emacs@gnu.org; Sun, 26 Nov 2017 09:17:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: charles@aurox.ch (Charles A. Roelli) Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 26 Nov 2017 14:17:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 28544 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 28544-submit@debbugs.gnu.org id=B28544.15117057761991 (code B ref 28544); Sun, 26 Nov 2017 14:17:02 +0000 Original-Received: (at 28544) by debbugs.gnu.org; 26 Nov 2017 14:16:16 +0000 Original-Received: from localhost ([127.0.0.1]:58690 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eIxjE-0000Vf-7S for submit@debbugs.gnu.org; Sun, 26 Nov 2017 09:16:16 -0500 Original-Received: from sinyavsky.aurox.ch ([37.35.109.145]:53552) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eIxjC-0000PQ-6K for 28544@debbugs.gnu.org; Sun, 26 Nov 2017 09:16:14 -0500 Original-Received: from sinyavsky.aurox.ch (sinyavsky.aurox.ch [127.0.0.1]) by sinyavsky.aurox.ch (Postfix) with ESMTP id 78B19225D9 for <28544@debbugs.gnu.org>; Sun, 26 Nov 2017 14:08:47 +0000 (UTC) Authentication-Results: sinyavsky.aurox.ch (amavisd-new); dkim=pass (1024-bit key) reason="pass (just generated, assumed good)" header.d=aurox.ch DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aurox.ch; h= references:subject:subject:in-reply-to:to:from:from:message-id :date:date; s=dkim; t=1511705325; x=1512569326; bh=SBuVmPheRsU4D A9CyXvIB1TtwD3YksrxDDLvw17rgj0=; b=n5fDw5sboF3y248q4Qr8fZeH4FlcC w6JKh6DVwoew+K0B19IcvOZHP5VyY8ODrQfhSz5yvCzhF6MIMs2ATHChRii1Vsxh iJzCqqGDWfIInQjq3EIm/+v39bLroQNer62RD3mViaZcndTR+Fo30/yFeR8ECDrf bTE7Rnt8fdUDSc= X-Virus-Scanned: Debian amavisd-new at test.virtualizor.com Original-Received: from sinyavsky.aurox.ch ([127.0.0.1]) by sinyavsky.aurox.ch (sinyavsky.aurox.ch [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id AY-xB7QFtW6H for <28544@debbugs.gnu.org>; Sun, 26 Nov 2017 14:08:45 +0000 (UTC) Original-Received: from gray (125.85.192.178.dynamic.wline.res.cust.swisscom.ch [178.192.85.125]) by sinyavsky.aurox.ch (Postfix) with ESMTPSA id 8EE7D225C0; Sun, 26 Nov 2017 14:08:45 +0000 (UTC) In-reply-to: (message from Sung Ho Kim on Wed, 20 Sep 2017 12:03:37 +0900) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:140407 Archived-At: > From: Sung Ho Kim > 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.