celery/billiard — pull request #74 by thekev (2013-10-09 19:01:47+00:00)
Title: do not catch SIGILL, SIGSEGV, SIGFPE. See CERT's SIG35-C

From SIG35-C: "According to the C Standard, subclause 7.14.1.1 [ISO/IEC 9899:2011], returning from a SIGSEGV, SIGILL, or SIGFPE signal handler is undefined behavior". We could have any number of serious problems causing these three signals, and the only safe thing to do, imo, is to crash immediately.

Although the signal handler may not return in python, the interpreter may be returning from its function, or doing other things out of our control. The problem this causes me is when a C++ library does something wrong, we end up in a race condition, looping on the signal (strace below).
```
[pid 29488] mmap(NULL, 2369249280, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMO
US, -1, 0) = 0x7f7ff6c82000
[pid 29488] --- SIGSEGV (Segmentation fault) @ 0 (0) ---
[pid 29488] rt_sigreturn(0xffffffff) = 140187577884712
[pid 29488] --- SIGSEGV (Segmentation fault) @ 0 (0) ---
[pid 29488] rt_sigreturn(0xb) = 140187577884712
...ad infinitum
```
The cause of the SEGV is our problem. I'm not sure if it has anything to do with SIG35-C's guideline, but when I unregistered the SEGV handler, my racing workers definitely went away so they could be respawned.
```
[2013-10-09 18:56:27,452: ERROR/MainProcess] Process 'PoolWorker-3' pid:14136 exited with exitcode -11
```