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

[Victor Stinner]

Le dimanche 19 décembre 2010 à 19:53 +0100, "Martin v. Löwis" a écrit :
> There should be at least one reviewer with an established track record
> of being interested/knowledgable in the POSIX APIs and cross-platform
> aspects of it.

Functions used by the fault handler:
 - write()
 - PyUnicode_Check()
 - PyFrame_GetLineNumber()
 - DebugBreak() (Windows, in debug mode, only)
 - abort()
 - (macro) PyUnicode_GET_SIZE() and PyUnicode_AS_UNICODE()
 - PyUnicode_Check(), PyFrame_Check()
 - PyFrame_GetLineNumber()
 - _Py_atomic_load_relaxed()
 - _PyThreadState_GetFrame()

I suppose that all *Py*() functions are POSIX compliants. DebugBreak()
is specific to Windows. Only write() and abort() have to be POSIX
compliant. According to Linux manual pages:

 - abort() conforms to SVr4, POSIX.1-2001, 4.3BSD, C89, C99.
 - write() conforms to SVr4, 4.3BSD, POSIX.1-2001

--

Functions used by the other parts of the patch:
 - signal() or sigaction()+sigemptyset()
 - (optional) sigaltstack()
 - PyMem_Malloc(), PyMem_Free()
 - Py_GETENV()
 - (optional) getpid(), kill() (used by the tests)

signal() conforms to C89, C99, POSIX.1-2001.

So I don't see any function incompatible with POSIX.

(Don't read old versions of my patch, read the latest version)

--

About the cross-platform question: it looks like SIGFPE fault is not
catchable on Windows. I only tried Linux and Windows, but there are a
unit test for each signal and we have 60+ buildbots with various
platforms. Can't we wait for the buildbot results?

> > Well, Python already does (and also apparently messes with other things
> > such as FPU state), so that's a separate issue altogether.
> 
> Not at all. Some signal handlers are more likely to interfere with the
> the rest of the application than others.

Python installs its own SIGINT handler. I think that a SIGINT handler is
more intrusive than a SIGSEGV or SIGILL handler.

Victor