> 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".