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#14474: 24.3.50; Zombie subprocesses (again) Date: Wed, 05 Jun 2013 10:21:46 -0700 Message-ID: <51AF73AA.3050609@cs.ucla.edu> References: <87ppwevddb.fsf@web.de> <51A24870.8020909@cs.ucla.edu> <87fvx93818.fsf@web.de> <51A2B88F.1090404@cs.ucla.edu> <1369658780.23869.57.camel@localhost> <51A9487B.5080805@cs.ucla.edu> <1370049737.19234.4.camel@localhost> <51A9915E.9010406@cs.ucla.edu> <1370275779.19234.17.camel@localhost> <51AD9533.4080709@cs.ucla.edu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1370452986 1823 80.91.229.3 (5 Jun 2013 17:23:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 5 Jun 2013 17:23:06 +0000 (UTC) Cc: Michael Heerdegen , Michael Albinus , 14474@debbugs.gnu.org To: Colin Walters Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Jun 05 19:23:05 2013 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 1UkHQO-0004Ss-A7 for geb-bug-gnu-emacs@m.gmane.org; Wed, 05 Jun 2013 19:23:04 +0200 Original-Received: from localhost ([::1]:42768 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UkHQN-00025y-TG for geb-bug-gnu-emacs@m.gmane.org; Wed, 05 Jun 2013 13:23:03 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40309) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UkHQJ-00025k-W9 for bug-gnu-emacs@gnu.org; Wed, 05 Jun 2013 13:23:01 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UkHQI-0006nJ-18 for bug-gnu-emacs@gnu.org; Wed, 05 Jun 2013 13:22:59 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:36183) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UkHQH-0006n8-Tg for bug-gnu-emacs@gnu.org; Wed, 05 Jun 2013 13:22:57 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1UkHSH-0006hX-NR for bug-gnu-emacs@gnu.org; Wed, 05 Jun 2013 13:25:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Paul Eggert Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 05 Jun 2013 17:25:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 14474 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 14474-submit@debbugs.gnu.org id=B14474.137045305125630 (code B ref 14474); Wed, 05 Jun 2013 17:25:01 +0000 Original-Received: (at 14474) by debbugs.gnu.org; 5 Jun 2013 17:24:11 +0000 Original-Received: from localhost ([127.0.0.1]:52772 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UkHRR-0006fI-He for submit@debbugs.gnu.org; Wed, 05 Jun 2013 13:24:10 -0400 Original-Received: from smtp.cs.ucla.edu ([131.179.128.62]:36312) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UkHRO-0006ei-K3 for 14474@debbugs.gnu.org; Wed, 05 Jun 2013 13:24:08 -0400 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id AEB95A60002; Wed, 5 Jun 2013 10:21:55 -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 unwD9GYo5d3O; Wed, 5 Jun 2013 10:21:54 -0700 (PDT) Original-Received: from penguin.cs.ucla.edu (Penguin.CS.UCLA.EDU [131.179.64.200]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id DA84CA60001; Wed, 5 Jun 2013 10:21:53 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6 In-Reply-To: <51AD9533.4080709@cs.ucla.edu> 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:74825 Archived-At: I found another problem with trying to have Emacs use glib's child watcher. glib's signal handling code uses SA_RESTART and SA_NOCLDSTOP. Both flags are non-starters for Emacs. SA_NOCLDSTOP, I suppose, could be conditionalized based on the discussion in Gnome bug reports 701538 and 562501. But SA_RESTART is more of a worry. An interactive Emacs doesn't want SA_RESTART, because Emacs wants long-running syscalls to be interrupted after a signal, not restarted. I thought of a way to work around this problem: have Emacs catch SIGCHLD using its own flags, and call glib's SIGCHLD handler as part of Emacs's SIGCHLD handler. So I installed the patch quoted at the end of this message into the Emacs trunk as bzr 112859. If you've had D-bus problems please try this new approach. This raises three more questions for glib, though. First, why does glib use SA_RESTART? If it's to avoid having application syscalls fail with errno==EINTR, then we're OK. But if it's to avoid having glib's internal syscalls fail with errno==EINTR, then we have a problem, as that can happen with the following patch (and it can also happen with vanilla Emacs 24.3). Second, should there be a more robust way for Emacs to invoke glib's SIGCHLD handler. The code below is a bit of a hack: it uses g_source_unref (g_child_watch_source_new (0)) to create and free a dummy SIGCHLD source, the only reason being to trick glib into installing its SIGCHLD handler. It also assumes that glib does not use SA_SIGINFO. This all seems fairly fragile. Third, if a glib memory allocation fails, what does Emacs do? Emacs tries hard not to exit when there's a memory allocation failure, but I worry that glib will simply call 'exit' if malloc fails, which is not good. === modified file 'src/ChangeLog' --- src/ChangeLog 2013-06-05 12:17:02 +0000 +++ src/ChangeLog 2013-06-05 17:04:13 +0000 @@ -1,3 +1,17 @@ +2013-06-05 Paul Eggert + + Chain glib's SIGCHLD handler from Emacs's (Bug#14474). + * process.c (dummy_handler): New function. + (lib_child_handler): New static var. + (handle_child_signal): Invoke it. + (catch_child_signal): If a library has set up a signal handler, + save it into lib_child_handler. + (init_process_emacs): If using glib and not on Windows, tickle glib's + child-handling code so that it initializes its private SIGCHLD handler. + * syssignal.h (SA_SIGINFO): Default to 0. + * xterm.c (x_term_init): Remove D-bus hack that I installed on May + 31; it should no longer be needed now. + 2013-06-05 Michael Albinus * emacs.c (main) [HAVE_GFILENOTIFY]: Call globals_of_gfilenotify. === modified file 'src/process.c' --- src/process.c 2013-06-03 18:47:35 +0000 +++ src/process.c 2013-06-05 17:04:13 +0000 @@ -6100,6 +6100,12 @@ might inadvertently reap a GTK-created process that happened to have the same process ID. */ +/* LIB_CHILD_HANDLER is a SIGCHLD handler that Emacs calls while doing + its own SIGCHLD handling. On POSIXish systems, glib needs this to + keep track of its own children. The default handler does nothing. */ +static void dummy_handler (int sig) {} +static signal_handler_t volatile lib_child_handler = dummy_handler; + /* Handle a SIGCHLD signal by looking for known child processes of Emacs whose status have changed. For each one found, record its new status. @@ -6184,6 +6190,8 @@ } } } + + lib_child_handler (sig); } static void @@ -7035,9 +7043,13 @@ void catch_child_signal (void) { - struct sigaction action; + struct sigaction action, old_action; emacs_sigaction_init (&action, deliver_child_signal); - sigaction (SIGCHLD, &action, 0); + sigaction (SIGCHLD, &action, &old_action); + eassert (! (old_action.sa_flags & SA_SIGINFO)); + if (old_action.sa_handler != SIG_DFL && old_action.sa_handler != SIG_IGN + && old_action.sa_handler != deliver_child_signal) + lib_child_handler = old_action.sa_handler; } @@ -7055,6 +7067,11 @@ if (! noninteractive || initialized) #endif { +#if defined HAVE_GLIB && !defined WINDOWSNT + /* Tickle glib's child-handling code so that it initializes its + private SIGCHLD handler. */ + g_source_unref (g_child_watch_source_new (0)); +#endif catch_child_signal (); } === modified file 'src/syssignal.h' --- src/syssignal.h 2013-01-02 16:13:04 +0000 +++ src/syssignal.h 2013-06-05 17:04:13 +0000 @@ -50,6 +50,10 @@ # define NSIG NSIG_MINIMUM #endif +#ifndef SA_SIGINFO +# define SA_SIGINFO 0 +#endif + #ifndef emacs_raise # define emacs_raise(sig) raise (sig) #endif === modified file 'src/xterm.c' --- src/xterm.c 2013-05-31 01:41:52 +0000 +++ src/xterm.c 2013-06-05 17:04:13 +0000 @@ -9897,13 +9897,6 @@ XSetLocaleModifiers (""); - /* If D-Bus is not already configured, inhibit D-Bus autolaunch, - as autolaunch can mess up Emacs's SIGCHLD handler. - FIXME: Rewrite subprocess handlers to use glib's child watchers. - See Bug#14474. */ - if (! egetenv ("DBUS_SESSION_BUS_ADDRESS")) - xputenv ("DBUS_SESSION_BUS_ADDRESS=unix:path=/dev/null"); - /* Emacs can only handle core input events, so make sure Gtk doesn't use Xinput or Xinput2 extensions. */ xputenv ("GDK_CORE_DEVICE_EVENTS=1");