[Python-Dev] Issue #8863 adds a new PYTHONNOFAULTHANDLER environment variable
victor.stinner at haypocalc.com
Sun Dec 19 22:59:01 CET 2010
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:
- DebugBreak() (Windows, in debug mode, only)
- (macro) PyUnicode_GET_SIZE() and PyUnicode_AS_UNICODE()
- PyUnicode_Check(), PyFrame_Check()
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()
- (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.
More information about the Python-Dev