[Python-Dev] Trap SIGSEGV and SIGFPE (original) (raw)

Alexander Belopolsky alexander.belopolsky at gmail.com
Thu Dec 11 01:21:06 CET 2008


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



More information about the Python-Dev mailing list