From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: nickrob@snap.net.nz (Nick Roberts) Newsgroups: gmane.emacs.bugs,gmane.emacs.pretest.bugs Subject: bug#4437: 23.1.50; Quitting gdb leaves a process behind Date: Tue, 22 Sep 2009 17:36:05 +1200 (NZST) Message-ID: <20090922053605.782A1C167@totara> References: <83ab0xfdrb.fsf@kalahari.s2.org> <19120.18090.883591.554535@totara.tehura.co.nz> <83zl8se82t.fsf@kalahari.s2.org> Reply-To: Nick Roberts , 4437@emacsbugs.donarmstrong.com NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1253598458 13062 80.91.229.12 (22 Sep 2009 05:47:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 22 Sep 2009 05:47:38 +0000 (UTC) Cc: 4437@emacsbugs.donarmstrong.com, emacs-pretest-bug@gnu.org To: Hannu Koivisto Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Sep 22 07:47:31 2009 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MpyDq-0000nE-Tu for geb-bug-gnu-emacs@m.gmane.org; Tue, 22 Sep 2009 07:47:31 +0200 Original-Received: from localhost ([127.0.0.1]:35483 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MpyDq-00086X-DK for geb-bug-gnu-emacs@m.gmane.org; Tue, 22 Sep 2009 01:47:30 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MpyDb-0007zY-10 for bug-gnu-emacs@gnu.org; Tue, 22 Sep 2009 01:47:15 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MpyDV-0007yN-83 for bug-gnu-emacs@gnu.org; Tue, 22 Sep 2009 01:47:13 -0400 Original-Received: from [199.232.76.173] (port=33549 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MpyDU-0007yF-J6 for bug-gnu-emacs@gnu.org; Tue, 22 Sep 2009 01:47:09 -0400 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:38065) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MpyDU-0006ed-0c for bug-gnu-emacs@gnu.org; Tue, 22 Sep 2009 01:47:08 -0400 Original-Received: from rzlab.ucr.edu (rzlab.ucr.edu [127.0.0.1]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n8M5l2KX004163; Mon, 21 Sep 2009 22:47:03 -0700 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.14.3/8.14.3/Submit) id n8M5j4Dt003855; Mon, 21 Sep 2009 22:45:04 -0700 Resent-Date: Mon, 21 Sep 2009 22:45:04 -0700 X-Loop: owner@emacsbugs.donarmstrong.com Resent-From: nickrob@snap.net.nz (Nick Roberts) Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs 2Resent-Date: Tue, 22 Sep 2009 05:45:04 +0000 Resent-Message-ID: Resent-Sender: owner@emacsbugs.donarmstrong.com X-Emacs-PR-Message: followup 4437 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Original-Received: via spool by 4437-submit@emacsbugs.donarmstrong.com id=B4437.12535978893073 (code B ref 4437); Tue, 22 Sep 2009 05:45:04 +0000 Original-Received: (at 4437) by emacsbugs.donarmstrong.com; 22 Sep 2009 05:38:09 +0000 X-Spam-Bayes: score:0.5 Bayes not run. spammytokens:Tokens not available. hammytokens:Tokens not available. Original-Received: from viper.snap.net.nz (viper.snap.net.nz [202.37.101.25]) by rzlab.ucr.edu (8.14.3/8.14.3/Debian-5) with ESMTP id n8M5c7Lr003070 for <4437@emacsbugs.donarmstrong.com>; Mon, 21 Sep 2009 22:38:09 -0700 Original-Received: from totara (81.63.255.123.dynamic.snap.net.nz [123.255.63.81]) by viper.snap.net.nz (Postfix) with ESMTP id 73A883D9EE0; Tue, 22 Sep 2009 17:37:56 +1200 (NZST) Original-Received: by totara (Postfix, from userid 1000) id 782A1C167; Tue, 22 Sep 2009 17:36:05 +1200 (NZST) In-Reply-To: <83zl8se82t.fsf@kalahari.s2.org> X-Mailer: VM 7.19 under Emacs 22.2.1 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Resent-Date: Tue, 22 Sep 2009 01:47:13 -0400 X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:31337 gmane.emacs.pretest.bugs:25068 Archived-At: > > If you want to run the same, but possibly newly compiled executable it's > > generally best not to quit GDB. GDB will automatically load the new code > > and it has the advantage of keeping shell history, breakpoints etc. You > > may need to change the line numbers on some breakpoints if the surrounding > > code has changed. > > Did you mean to give this advice as a workaround for the leakage > problem? No. I mean there's generally no need to type 'quit' in the GUD buffer. I've reverted an inadvertant change, so any recent problems (last few days) should disappear. It's still not ideal and you can find further problems if you look for them > Sure. I can even restart Emacs, I have no problem living > with the problem till it gets fixed. It should now be enough to kill the GUD buffer. > As a general comment to this history stuff, it wouldn't be a bad > feature if Emacs could provide history and breakpoint persistence > over gud/gdb sessions. I think it might be hard to implement. GDB has it's own history on the command line using: set history save on Now Emacs uses GDB/MI, commands from the GUD buffer don't go into that history so Emacs would need to emulate GDB's behaviour. > For what it's worth, I now know how to reproduce this one. All I > need to do in addition to what I did to reproduce the leakage > problem is to set a temporary breakpoint to main function and "run" > to it before invoking quit. I think this is related to the change I made to process.c below. This allows the I/O buffer to work when the inferior is restarted but means that status_notify isn't called from wait_reading_process_output because this call is conditioned on select which returns a positive value (presumably because the pty's file descriptor hasn't been cleared). Reverting it means processes aren't left lying around but that leaves the original problem. I mention this in case someone who knows process.c better than me can see a way around it. -- Nick http://www.inet.net.nz/~nickrob Index: process.c =================================================================== RCS file: /sources/emacs/emacs/src/process.c,v retrieving revision 1.594 retrieving revision 1.595 diff -c -p -r1.594 -r1.595 *** process.c 27 Aug 2009 11:12:54 -0000 1.594 --- process.c 30 Aug 2009 04:54:34 -0000 1.595 *************** wait_reading_process_output (time_limit, *** 5150,5160 **** It can't hurt. */ else if (nread == -1 && errno == EIO) { ! /* Clear the descriptor now, so we only raise the signal once. */ ! FD_CLR (channel, &input_wait_mask); ! FD_CLR (channel, &non_keyboard_wait_mask); ! kill (getpid (), SIGCHLD); } #endif /* HAVE_PTYS */ /* If we can detect process termination, don't consider the process --- 5150,5165 ---- It can't hurt. */ else if (nread == -1 && errno == EIO) { ! /* Clear the descriptor now, so we only raise the ! signal once. Don't do this is `process' is only ! a pty. */ ! if (XPROCESS (proc)->pid != -2) ! { ! FD_CLR (channel, &input_wait_mask); ! FD_CLR (channel, &non_keyboard_wait_mask); ! kill (getpid (), SIGCHLD); ! } } #endif /* HAVE_PTYS */ /* If we can detect process termination, don't consider the process