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.
syssignap.txt.gz
Description: GNU Zip compressed data
--- End Message ---