[Python-Dev] Trap SIGSEGV and SIGFPE

[Alexander Belopolsky]

On Wed, Dec 10, 2008 at 6:12 PM, "Martin v. Löwis" <martin at v.loewis.de> wrote:
>> I would appreciate a review, especially for the patch in Python/ceval.c.
>
> In this specific case, it is not clear for what objective you want such
> review. For inclusion into Python?
>

Even if it does not result in an inclusion into Python, I personally
would be quite interested in following this thread if discussion of
Victor's patch continues.  It may quite possibly yield some
improvements to python development tools (core and libraries'
development).  Graceful handling of hard errors is an unsolved problem
in Python and it has become more important since ctypes made it to the
standard library and therefore it has become possible to easily
trigger a hard error from pure python code.

> Several people already said (essentially) that: -1. I don't think such
> code should be added to the Python core, no matter how smart or correct
> it is.
>

Looking up the thread, I don't see anyone taking such an extreme
position: never recover from SEGV even if it can be done 100%
correctly.  The sentiment that I see and the one that I share is that
it is extremely difficult (and maybe impossible) to do correctly.
However, if someone comes up with a smart solution, I would be very
much interested to see it.

While by the time you get a SIGSEGV, you process is likely to be
beyond recovery, I don't think the same applies to SIGFPE.   It may
also be possible to get rid of the arbitrary recursion limit on Linux
(I've heard this problem is solved on Windows) by being smart about
handling SIGSEGV.

Finally, providing some diagnostic before exiting on hard errors is
not without precedent: I believe R has such a feature.  It may be
worthwhile to compare Victor's approach to what is done in R.

It may, however, be better to move further discussion to the tracker
(I understand that the patch is at
<http://bugs.python.org/issue3999>).