[Python-Dev] Issue #8863 adds a new PYTHONNOFAULTHANDLER environment variable

[Victor Stinner]

Le samedi 18 décembre 2010 à 08:50 -0500, James Y Knight a écrit :
> I think instead of calling abort() to kill the process, you should:
> - install the signal handler with SA_NODEFER|SA_RESETHAND (or if sigaction is not present, explicitly reset the action to SIG_DFL and unblock first thing upon entering the handler), and then,
> - at the end of the handler, kill(getpid(), orig_signal) in order to abort the process.

I don't think that kill() is available on Windows.

We may call directly the previous handler in the new handler, but it is
more difficult. It looks like the prototype of a signal handler depends
on its options. Or is it possible to always pass (signum, siginfo,
ucontext) arguments? I don't know if siginfo and ucontect are portable
or not...

Another possible approach is to restore the previous handler in the
fault handler, and don't call abort(). The fault should occur again, and
so the previous signal handler will be called.

I choosed to not call the previous handler to keep the patch simple. If
you consider that we must call the previous handler, I can work on a new
patch doing that.

> This has two advantages: 1) the process's exit code will actually show the correct signal

Oh, I didn't noticed that the exit code is different.

> 2) it might let the OS fault handlers work properly as well -- I'm not sure. If it does, you may want to experiment with whether having or omitting SA_NODEFER gives a better backtrace (from the OS mechanism) in that case.

For the OS fault handler: we should try, I am not sure that calling
another signal handler (my fault handler) keeps the process state
unchanged (especially if sigaltstk() is not available).

I don't understand the SA_NODEFER option. What does it change for this
fault handler?

> If #2 actually works, you may not even need the env var, which would be nice.

I prefer to keep it optional because we don't know yet how it interacts
exactly with existing debug tools, OS tools, embedded Python
interpreters, etc.

Victor