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#12471: Avoid some signal-handling races, and simplify. Date: Wed, 19 Sep 2012 19:18:41 +0300 Message-ID: <83lig6yoim.fsf@gnu.org> References: <50590626.2070407@cs.ucla.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1348071593 10488 80.91.229.3 (19 Sep 2012 16:19:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 19 Sep 2012 16:19:53 +0000 (UTC) Cc: 12471@debbugs.gnu.org, lekktu@gmail.com To: Paul Eggert Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Sep 19 18:19:56 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 1TEN0B-00037I-0I for geb-bug-gnu-emacs@m.gmane.org; Wed, 19 Sep 2012 18:19:51 +0200 Original-Received: from localhost ([::1]:34501 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TEN06-0005R4-Jy for geb-bug-gnu-emacs@m.gmane.org; Wed, 19 Sep 2012 12:19:46 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:57366) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TEN02-0005Qq-Vm for bug-gnu-emacs@gnu.org; Wed, 19 Sep 2012 12:19:44 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TEMzw-0000Sw-LM for bug-gnu-emacs@gnu.org; Wed, 19 Sep 2012 12:19:42 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:34300) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TEMzw-0000Sp-BQ for bug-gnu-emacs@gnu.org; Wed, 19 Sep 2012 12:19:36 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TEN1K-00042a-9D for bug-gnu-emacs@gnu.org; Wed, 19 Sep 2012 12:21:02 -0400 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: Wed, 19 Sep 2012 16:21:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 12471 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch X-Debbugs-Original-Cc: lekktu@gmail.com, bug-gnu-emacs@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.134807163815490 (code B ref -1); Wed, 19 Sep 2012 16:21:02 +0000 Original-Received: (at submit) by debbugs.gnu.org; 19 Sep 2012 16:20:38 +0000 Original-Received: from localhost ([127.0.0.1]:43845 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TEN0w-00041n-FL for submit@debbugs.gnu.org; Wed, 19 Sep 2012 12:20:38 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:54483) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TEN0v-00041g-2P for submit@debbugs.gnu.org; Wed, 19 Sep 2012 12:20:38 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TEMzQ-0000HH-SU for submit@debbugs.gnu.org; Wed, 19 Sep 2012 12:19:10 -0400 Original-Received: from lists.gnu.org ([208.118.235.17]:44040) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TEMzQ-0000HD-Pw for submit@debbugs.gnu.org; Wed, 19 Sep 2012 12:19:04 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:57262) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TEMzK-0005NS-Sz for bug-gnu-emacs@gnu.org; Wed, 19 Sep 2012 12:19:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TEMz9-0000Bo-IH for bug-gnu-emacs@gnu.org; Wed, 19 Sep 2012 12:18:58 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:55550) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TEMz9-0000BA-AB for bug-gnu-emacs@gnu.org; Wed, 19 Sep 2012 12:18:47 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MAL00400UKZ7E00@a-mtaout20.012.net.il> for bug-gnu-emacs@gnu.org; Wed, 19 Sep 2012 19:18:29 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MAL003RHUMT8BR0@a-mtaout20.012.net.il>; Wed, 19 Sep 2012 19:18:29 +0300 (IDT) In-reply-to: <50590626.2070407@cs.ucla.edu> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) 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 (newer, 2) 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:64604 Archived-At: > Date: Tue, 18 Sep 2012 16:39:18 -0700 > From: Paul Eggert > CC: Eli Zaretskii , Juanma Barranquero > > Attached is a patch to fix some of the problems that I found, and to > simplify nearby signal-handling code. Thanks. I have a few questions/comments: -#define UNBLOCK_INPUT \ - do \ - { \ - --interrupt_input_blocked; \ - if (interrupt_input_blocked == 0) \ - { \ - if (interrupt_input_pending) \ - reinvoke_input_signal (); \ - if (pending_atimers) \ - do_pending_atimers (); \ - } \ - else if (interrupt_input_blocked < 0) \ - emacs_abort (); \ - } \ - while (0) +extern void unblock_input (void); Why is it a good idea to replace this macro with a function? The macro is used quite frequently in the code; replacing it with a function might slow down Emacs, and for what good reason? +extern void UNBLOCK_INPUT_TO (int); A function whose name is in CAPS? Why? /* Report a fatal error due to signal SIG, output a backtrace of at most BACKTRACE_LIMIT lines, and exit. */ _Noreturn void -fatal_error_backtrace (int sig, int backtrace_limit) +terminate_due_to_signal (int sig, int backtrace_limit) { fatal_error_code = sig; - signal (sig, SIG_DFL); TOTALLY_UNBLOCK_INPUT; @@ -316,9 +302,8 @@ } /* Signal the same code; this time it will really be fatal. - Remember that since we're in a signal handler, the signal we're - going to send is probably blocked, so we have to unblock it if we - want to really receive it. */ + Since we're in a signal handler, the signal is blocked, so we + have to unblock it if we want to really receive it. */ #ifndef MSDOS { sigset_t unblocked; @@ -328,7 +313,7 @@ } #endif - kill (getpid (), fatal_error_code); + raise (fatal_error_code); If there are good reasons to prefer 'raise' to 'kill' in this context, can we please special-case SIGABRT here and call 'emacs_abort' directly, at least for hosts that cannot produce the backtrace? Otherwise, assertion violations will not end up in 'emacs_abort', AFAICS. static void deliver_interrupt_signal (int sig) { - handle_on_main_thread (sig, handle_interrupt_signal); + deliver_process_signal (sig, handle_interrupt_signal); } Do we really need this double indirection? Why not call deliver_process_signal directly (here and elsewhere)? -#ifdef SIGTERM parse_signal ("term", SIGTERM); -#endif I don't understand why did you remove the conditional. This won't compile if SIGTERM isn't defined. Did you assume that it is always available? + if (! IEEE_FLOATING_POINT) + sigaddset (&action->sa_mask, SIGFPE); Why is IEEE_FLOATING_POINT, which detects the representation of FP numbers, related to SIGFPE? -# ifdef SIGTERM sys_siglist[SIGTERM] = "Terminated"; -# endif This won't compile if SIGTERM is not defined. + maybe_fatal_sig (SIGTERM); Same here. + sigaction (SIGTERM, &process_fatal_action, 0); And here. + if (! IEEE_FLOATING_POINT) + { + emacs_sigaction_init (&action, deliver_arith_signal); + sigaction (SIGFPE, &action, 0); + } See above: why? - return ret; + return nev; This should be in a separate commit, as it is unrelated.