STINNER Victor added the comment: > I've found a few examples of handling non-restartable signals > with longjmps, but not that familiar with the codebase to estimate > how reliably it can be done on all supported platforms. > I don't really know how this code would behave, say, on Windows.
I proposed a generic signal handler for SIGSEGV (SIGFPE, SIGILL and SIGBUS) converting the fatal signal to a classic Python exception: issue issue #3999. The idea was rejected by most core developers because it's just impossible to guarantee that Python internal structures are still consistent. A signal can occur anywhere, the longjmp() will skip all "cleanup" instructions and so it's easy to get into a deadlock case. So I proposed to display a Python traceback on such signal and just exit. For your specific case, it would much better if the kernel handles the case. > I thought that the possibility to crash the interpreter > is something to be avoided at all costs. It's quite easy to crash Python using extensions implemented in C. A simple example: ctypes.string_at(0). For your specific case, you should develop an extension which sets a signal handler before reading the mmap and then restore the old signal handler after. It might be safe if the signal handler protects a single instruction, but it's very hard to develop a signal handler for such critical signals (SIGSEGV and friends). I suggest to just close this issue as "wont fix". Python cannot do anything useful in a safe manner against this "OS bug". ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue16212> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
