unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Paul Eggert <eggert@cs.ucla.edu>
To: 12471@debbugs.gnu.org
Cc: Juanma Barranquero <lekktu@gmail.com>
Subject: bug#12471: Avoid some signal-handling races, and simplify.
Date: Tue, 18 Sep 2012 16:39:18 -0700	[thread overview]
Message-ID: <50590626.2070407@cs.ucla.edu> (raw)

[-- Attachment #1: Type: text/plain, Size: 2040 bytes --]

Tags: patch

I looked through emacs for race conditions involving signals and found
some problems, including:

 * Signal handlers can interrupt each other, leading to races.

 * Signals can be mishandled if they arrive right in the middle of
   code that is keeping track of whether signals have arrived.

 * Some variables are modified by signal handlers but are not
   declared 'volatile', which means accesses to them could be
   incorrectly optimized.

 * When debugging, the debugging code can get into an infinite
   signal-handling loop if there's a bug in the fatal error handler.

 * There are some bugs involving running out of memory in the middle
   of a vfork, in which signal handlers aren't restored correctly and
   Emacs is likely to misbehave.

 * Signals are always redirected to the main thread, resulting in
   incorrect backtraces when, for example, a subsidiary thread has
   a segmentation violation.  Thread-specific signals like SIGSEGV
   should have thread-specific backtraces.

 * When in batch mode, Emacs doesn't ignore SIGINT if the invoker has
   purposely ignored SIGINT.  Similarly for SIGTERM.  Emacs gets
   SIGHUP right, but the other two signals should be consistent
   with the usual behavior for batch programs.

 * Emacs isn't consistent about what tests it uses to decide whether
   it is in batch mode, leading to glitches when the tests disagree.

 * Emacs catches SIGPIPE, but it's better to ignore it, as this avoids
   races.

 * Emacs catches SIGFPE, but on IEEE hosts catching SIGFPE isn't
   needed and can mask bugs; it's better to catch SIGFPE only on (the
   now quite rare) non-IEEE hosts.

Attached is a patch to fix some of the problems that I found, and to
simplify nearby signal-handling code.  I'd like to install this into
the trunk before it freezes.  The patch is about 3300 lines so I've
taken the liberty of compressing it with gzip.

This patch affects a few bits of the Windows code; I haven't tested
that part.  I'm CC:ing this to Eli and Juanma to give them a heads-up.


[-- Attachment #2: syssignap.txt.gz --]
[-- Type: application/x-gzip, Size: 28446 bytes --]

             reply	other threads:[~2012-09-18 23:39 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-18 23:39 Paul Eggert [this message]
2012-09-19 16:18 ` bug#12471: Avoid some signal-handling races, and simplify Eli Zaretskii
2012-09-20  6:07   ` Paul Eggert
2012-09-20 17:44     ` Eli Zaretskii
2012-09-21  7:42       ` Paul Eggert
2012-09-21  8:31         ` Eli Zaretskii
2012-09-21 17:26           ` Paul Eggert
2012-09-21 17:38             ` Eli Zaretskii
2012-09-21 18:13               ` Paul Eggert
2012-09-21 18:27                 ` Eli Zaretskii
2012-09-21 19:59                   ` Paul Eggert
2012-09-22  8:02                     ` Eli Zaretskii
2012-09-22  8:47                       ` Paul Eggert
2012-09-22  9:10                         ` Eli Zaretskii
2012-09-22  9:40                           ` Paul Eggert
2012-09-22 10:07                             ` Eli Zaretskii
2012-09-22 10:55                               ` Paul Eggert
2012-09-22 11:16                                 ` Eli Zaretskii
2012-09-22 20:28                               ` Stefan Monnier
2012-09-22 21:55                                 ` Paul Eggert
2012-09-23  3:55                                   ` Eli Zaretskii
2012-09-23  3:52                                 ` Eli Zaretskii
2012-09-19 16:45 ` Jan Djärv
2012-09-19 19:58   ` Paul Eggert
2012-09-20  6:27     ` Jan Djärv
2012-09-19 21:36 ` Andy Moreton
2012-09-23  9:36 ` bug#12471: installed into trunk Paul Eggert
2012-09-23 15:22   ` Andy Moreton
2012-09-23 16:23     ` Andy Moreton
2012-09-23 17:37       ` Juanma Barranquero
2012-09-23 17:37     ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50590626.2070407@cs.ucla.edu \
    --to=eggert@cs.ucla.edu \
    --cc=12471@debbugs.gnu.org \
    --cc=lekktu@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).