At the beginning of the test suit execution, faulthandler registers its signal handler for fatal signals, as well as SIGUSR1 and SIGALRM.

The problem is that some tests temporary change those handlers, e.g. for EINTR-handling tests.
While they do restore the original handlers after the test, this doesn't work as expected because of an artifact of the signal implementation: when a signal handler isn't registered through the signal module (e.g. directly from C for faulthandler), getsignal() and setsignal() return None/SIG_DFL (depending on whether it was registered before or after the module initialization). Which means that when the test is done, it will restore the default signal handler, and not the faulthandler's one. Thus, any subsequent crash due to this signal won't benefit from faulthandler debug output, see e.g. (issue #18786):
http://buildbot.python.org/all/builders/PPC64%20PowerLinux%203.x/builds/616/steps/test/logs/stdio
"""
[310/379] test_multiprocessing_spawn
make: *** [buildbottest] User defined signal 1
/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/multiprocessing/semaphore_tracker.py:121: UserWarning: semaphore_tracker: There appear to be 4 leaked semaphores to clean up at shutdown
  len(cache))
program finished with exit code 2
elapsedTime=2459.665997
"""

One way to fix this would be to add a WithSignalHandler(signal, handler) context manager to test.support that would replace the signal handler upon entry, and re-register faulthandler's handler upon exit.

See also issue 3948 for another variation of this problem with getsignal/setsignal.

Or perhaps we could enhance the signal module so that getsignal() return something (i.e. a specific object) which can restore the C signal handler. That would be better than special-casing faulthandler, IMHO.

> Or perhaps we could enhance the signal module so that getsignal() return something (i.e. a specific object) which can restore the C signal handler. That would be better than special-casing faulthandler, IMHO.

Yes, I thought about that, see http://bugs.python.org/msg146560
The only problem I saw at that time is that we must make sure that the
object is indeed valid, otherwise the signal handler can jump to an
invalid address, and boom.

> > Or perhaps we could enhance the signal module so that getsignal() return something (i.e. a specific object) which can restore the C signal handler. That would be better than special-casing faulthandler, IMHO.
> 
> Yes, I thought about that, see http://bugs.python.org/msg146560
> The only problem I saw at that time is that we must make sure that the
> object is indeed valid, otherwise the signal handler can jump to an
> invalid address, and boom.

Well, to make sure the object is valid, you can just ensure instances
can't be created from Python (for example, make tp_new raise an error),
and that the internal state can't be mutated.

"One way to fix this would be to add a WithSignalHandler(signal, handler) context manager to test.support that would replace the signal handler upon entry, and re-register faulthandler's handler upon exit."

faulthandler.dump_traceback_later() is registered before each test, in test.regrtest.runtest().

You may reinstall signal handlers before each test, or fix signal.getsignal() and signal.signal(). I don't have a preference.

I'll tackle #13285 instead.