From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.bugs Subject: bug#17561: Emacs can forget processes Date: Mon, 26 May 2014 10:08:38 -0700 Organization: UCLA Computer Science Department Message-ID: <53837516.3070508@cs.ucla.edu> References: <537F773C.8060202@cs.ucla.edu> <20140523184419.70fe136d@forcix.jorgenschaefer.de> <538124C0.8080107@cs.ucla.edu> <20140525095735.6cfac9af@forcix.jorgenschaefer.de> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1401124231 25392 80.91.229.3 (26 May 2014 17:10:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 26 May 2014 17:10:31 +0000 (UTC) Cc: 17561@debbugs.gnu.org To: Jorgen Schaefer Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon May 26 19:10:24 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WoyPl-0006QG-Ft for geb-bug-gnu-emacs@m.gmane.org; Mon, 26 May 2014 19:10:21 +0200 Original-Received: from localhost ([::1]:57708 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WoyPk-0000Lm-JB for geb-bug-gnu-emacs@m.gmane.org; Mon, 26 May 2014 13:10:20 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53239) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WoyPa-00009o-QY for bug-gnu-emacs@gnu.org; Mon, 26 May 2014 13:10:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WoyPT-0003Cr-8b for bug-gnu-emacs@gnu.org; Mon, 26 May 2014 13:10:10 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:33540) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WoyPT-0003BT-4w for bug-gnu-emacs@gnu.org; Mon, 26 May 2014 13:10:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1WoyPS-0002Io-8v for bug-gnu-emacs@gnu.org; Mon, 26 May 2014 13:10:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 26 May 2014 17:10:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17561 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 17561-submit@debbugs.gnu.org id=B17561.14011241418754 (code B ref 17561); Mon, 26 May 2014 17:10:02 +0000 Original-Received: (at 17561) by debbugs.gnu.org; 26 May 2014 17:09:01 +0000 Original-Received: from localhost ([127.0.0.1]:60650 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WoyOS-0002Gz-EY for submit@debbugs.gnu.org; Mon, 26 May 2014 13:09:01 -0400 Original-Received: from smtp.cs.ucla.edu ([131.179.128.62]:41485) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WoyOP-0002Gi-V7 for 17561@debbugs.gnu.org; Mon, 26 May 2014 13:08:58 -0400 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id C3396A6000B; Mon, 26 May 2014 10:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Original-Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HwyvQPENCtOZ; Mon, 26 May 2014 10:08:42 -0700 (PDT) Original-Received: from [192.168.1.9] (pool-108-0-233-62.lsanca.fios.verizon.net [108.0.233.62]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 1064AA60008; Mon, 26 May 2014 10:08:42 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 In-Reply-To: <20140525095735.6cfac9af@forcix.jorgenschaefer.de> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.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-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:89501 Archived-At: Jorgen Schaefer wrote: > The trace starts with a number of these triplets, which seem to be > "Emacs behaving normally". > > 16300 09:41:27.072717 pselect6(20, [3 4 5 6 8 10 14 15 19], [], NULL, {0, 176410474}, {NULL, 8}) = 0 (Timeout) <0.176635> > 16300 09:41:27.249649 rt_sigprocmask(SIG_BLOCK, [WINCH IO], NULL, 8) = 0 <0.000011> > 16300 09:41:27.249881 rt_sigprocmask(SIG_UNBLOCK, [WINCH IO], NULL, 8) = 0 <0.000010> I don't observe this behavior when running Emacs on Fedora 20 (this is the latest emacs-24 version, running your little test). I ran: strace -o /tmp/tr -fttT src/bootstrap-emacs -nw -Q I did see this: 29589 09:44:10.979952 ioctl(4, FIONREAD, [0]) = 0 <0.000023> 29589 09:44:10.980031 ioctl(4, FIONREAD, [0]) = 0 <0.000024> 29589 09:44:10.980143 pselect6(6, [4 5], [], NULL, {0, 499810466}, {NULL, 8}) = 0 (Timeout) <0.500499> 29589 09:44:11.480745 poll([{fd=5, events=POLLIN}], 1, 0) = 0 (Timeout) <0.000030> 29589 09:44:11.480861 read(5, 0x7fff777b3820, 16) = -1 EAGAIN (Resource temporarily unavailable) <0.000029> 29589 09:44:11.481214 rt_sigprocmask(SIG_BLOCK, [WINCH IO], NULL, 8) = 0 <0.000030> 29589 09:44:11.481505 rt_sigprocmask(SIG_UNBLOCK, [WINCH IO], NULL, 8) = 0 <0.000027> 29589 09:44:11.481594 ioctl(4, FIONREAD, [0]) = 0 <0.000030> but that's not really the same. Could you please try running emacs -nw -Q with your test case, and see whether it behaves like the pattern on my platform? If so, we might try to investigate why Emacs changes from this pattern to the pattern that you observe. > Then there's a large bunch of syscalls related to my command to restart > the process, with the "\r" now being me sending the M-x command: Which M-x command was that? M-x list-processes? > 16300 09:41:28.298391 read(3, "\r", 1) = 1 <0.000012> > 16300 09:41:28.298438 ioctl(3, FIONREAD, [0]) = 0 <0.000009> > 16300 09:41:28.298480 ioctl(3, FIONREAD, [0]) = 0 <0.000009> > 16300 09:41:28.312476 write(3, "\r", 1) = 1 <0.000021> > 16300 09:41:28.317392 kill(4294953129, SIGHUP) = 0 <0.002235> > 16300 09:41:28.321642 rt_sigprocmask(SIG_BLOCK, [WINCH IO], NULL, 8) = 0 <0.000017> > 16300 09:41:28.321841 write(3, "\33[K\33[H\n\n", 8) = 8 <0.000018> > 16300 09:41:28.321909 rt_sigprocmask(SIG_UNBLOCK, [WINCH IO], NULL, 8) = 0 <0.000012> When I try your test, the child process is running in parallel with the parent, the 'kill' terminates the child, and the parent is signaled. In contrast your trace shows no child, leading me to guess that the child has already exited (so the parent is killing a zombie), which means it's not the test case you sent but some other process (since the test case you sent waits on a pty so the child shouldn't exit). Here's the trace I see around the kill: 29592 09:44:24.494089 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) <0.000028> 29589 09:44:24.494167 kill(4294937704, SIGHUP 29592 09:44:24.494199 open("/usr/lib64/alliance/lib/tls/x86_64/libc.so.6", O_RDONLY|O_CLOEXEC 29589 09:44:24.494218 <... kill resumed> ) = 0 <0.000040> 29592 09:44:24.494236 <... open resumed> ) = -1 ENOENT (No such file or directory) <0.000025> 29592 09:44:24.494267 --- SIGHUP {si_signo=SIGHUP, si_code=SI_USER, si_pid=29589, si_uid=1000} --- 29592 09:44:24.494375 +++ killed by SIGHUP +++ 29589 09:44:24.494388 --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_KILLED, si_pid=29592, si_status=SIGHUP, si_utime=0, si_stime=0} --- 29589 09:44:24.494435 wait4(29592, [{WIFSIGNALED(s) && WTERMSIG(s) == SIGHUP}], WNOHANG|WSTOPPED|WCONTINUED, NULL) = 29592 <0.000037> 29589 09:44:24.494507 rt_sigreturn() = 12159536 <0.000021> 29589 09:44:24.494603 rt_sigprocmask(SIG_BLOCK, [ALRM], NULL, 8) = 0 <0.000019> 29589 09:44:24.494653 rt_sigprocmask(SIG_UNBLOCK, [ALRM], NULL, 8) = 0 <0.000017> 29589 09:44:24.495590 rt_sigprocmask(SIG_BLOCK, [WINCH IO], NULL, 8) = 0 <0.000025> 29589 09:44:24.496152 write(4, "\r\n\33[?25lnil\33[48;34H\33[7m11\33[0m\33[3"..., 70) = 70 <0.000036> 29589 09:44:24.496236 rt_sigprocmask(SIG_UNBLOCK, [WINCH IO], NULL, 8) = 0 <0.000015> 29589 09:44:24.496282 --- SIGIO {si_signo=SIGIO, si_code=SI_KERNEL} --- 29589 09:44:24.496306 rt_sigreturn() = 0 <0.000015> 29589 09:44:24.496350 ioctl(4, FIONREAD, [0]) = 0 <0.000016> Perhaps you could run your test on a fresh emacs -Q -nw and see whether it matches the behavior I'm seeing. > Killing the process via the process list (hence the "d"): You typed "d" in the window generated by M-x list-processes? When I try that, it says "d is undefined". > My Emacs sessions usually have a number of processes open. When the bug > showed up just now, it was five processes and three network connections, > for example. I'm not sure if that's related. I expect that it is, unfortunately.