From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#12980: 24.3.50; Zombie process left after call-process Date: Thu, 29 Nov 2012 20:04:55 +0200 Message-ID: <83pq2wuvy0.fsf@gnu.org> References: <50B3EF71.3020805@cs.ucla.edu> <83ehjfxcg7.fsf@gnu.org> <50B6C8B0.3000403@cs.ucla.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1354212330 16224 80.91.229.3 (29 Nov 2012 18:05:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 29 Nov 2012 18:05:30 +0000 (UTC) Cc: 9488@debbugs.gnu.org, hanche@math.ntnu.no, 12980@debbugs.gnu.org To: Paul Eggert Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Nov 29 19:05:41 2012 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 1Te8US-0001b4-Kv for geb-bug-gnu-emacs@m.gmane.org; Thu, 29 Nov 2012 19:05:36 +0100 Original-Received: from localhost ([::1]:48802 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Te8UD-0002FV-VB for geb-bug-gnu-emacs@m.gmane.org; Thu, 29 Nov 2012 13:05:21 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:39328) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Te8U4-000291-Q9 for bug-gnu-emacs@gnu.org; Thu, 29 Nov 2012 13:05:19 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Te8Tt-0005Js-LA for bug-gnu-emacs@gnu.org; Thu, 29 Nov 2012 13:05:12 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:35241) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Te8Tt-0005JI-IZ for bug-gnu-emacs@gnu.org; Thu, 29 Nov 2012 13:05:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1Te8Vp-00074j-IU for bug-gnu-emacs@gnu.org; Thu, 29 Nov 2012 13:07:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 29 Nov 2012 18:07:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 12980 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 12980-submit@debbugs.gnu.org id=B12980.135421240827173 (code B ref 12980); Thu, 29 Nov 2012 18:07:01 +0000 Original-Received: (at 12980) by debbugs.gnu.org; 29 Nov 2012 18:06:48 +0000 Original-Received: from localhost ([127.0.0.1]:45490 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Te8Vc-00074E-7Q for submit@debbugs.gnu.org; Thu, 29 Nov 2012 13:06:48 -0500 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:38624) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Te8VZ-000743-Ox; Thu, 29 Nov 2012 13:06:47 -0500 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0ME900800GR9W400@a-mtaout22.012.net.il>; Thu, 29 Nov 2012 20:04:34 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0ME9008QPGVMW700@a-mtaout22.012.net.il>; Thu, 29 Nov 2012 20:04:34 +0200 (IST) In-reply-to: <50B6C8B0.3000403@cs.ucla.edu> X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.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:67593 Archived-At: > Date: Wed, 28 Nov 2012 18:30:08 -0800 > From: Paul Eggert > CC: hanche@math.ntnu.no, 12980@debbugs.gnu.org, 9488@debbugs.gnu.org > > > The feature, whereby this function (call-process) could return a > > description of errno, is hereby lost. That's quite nasty in the MSDOS > > case > > That feature is supported only by MS-DOS, right? Yes, I think so. > On all other platforms an error is thrown. Anyway, the new patch > attempts to preserve the MS-DOS behavior. Thanks. > > Why is this eassert a good idea? We don't need to enforce the Posix > > spec at a price of crashing Emacs on users, do we? What bad things > > can happen if you see some other errno here? > > It's not a question of enforcing Posix semantics. It's a > question of catching potentially serious internal > programming errors in Emacs. That part of the code has been > completely rewritten, so the details of the comment is moot. > However, the new code has an "eassert (errno == EINTR)" in > the new get_child_status function. I preceded that with a > comment to try to help explain why the eassert is there. Here's the comment: > + /* CHILD must be a child process that has not been reaped, and > + STATUS and OPTIONS must be valid. */ > + eassert (errno == EINTR); Are we sure that either CHILD will have exited at this point, or else OPTIONS won't include WNOHANG? Can this function be ever called if neither of these conditions is true? > > it would be nice to have somewhere a commentary with an > > overview of how termination of child processes is handled. > > I added some, before handle_child_signal. Thanks. > - if (synch_process_termsig) > + if (WIFSIGNALED (status)) > { > const char *signame; > > synchronize_system_messages_locale (); > - signame = strsignal (synch_process_termsig); > + signame = strsignal (WTERMSIG (status)); > > if (signame == 0) > signame = "unknown"; > > - synch_process_death = signame; > + return code_convert_string_norecord (build_string (signame), > + Vlocale_coding_system, 0); > } > > - if (synch_process_death) > - return code_convert_string_norecord (build_string (synch_process_death), > - Vlocale_coding_system, 0); > - return make_number (synch_process_retcode); > + eassert (WIFEXITED (status)); > + return make_number (WEXITSTATUS (status)); The use of WIF* macros here, in particular WIFSIGNALED and WTERMSIG, will probably require more accurate definitions of these for Windows (currently, they are quite naive and therefore wrong). But that can wait. Otherwise, I see no problems related to Windows. Thanks!