[Python-Dev] Issue #8863 adds a new PYTHONNOFAULTHANDLER environment variable (original) (raw)

Victor Stinner victor.stinner at haypocalc.com
Mon Dec 20 00:02:25 CET 2010

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 SANODEFER|SARESETHAND (or if sigaction is not present, explicitly reset the action to SIGDFL and unblock first thing upon entering the handler), and then, - at the end of the handler, kill(getpid(), origsignal) 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 SANODEFER 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

More information about the Python-Dev mailing list