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

Adam Olsen rhamph at gmail.com
Thu Dec 11 02:01:45 CET 2008

On Wed, Dec 10, 2008 at 5:21 PM, Alexander Belopolsky <alexander.belopolsky at gmail.com> wrote:

On Wed, Dec 10, 2008 at 6:12 PM, "Martin v. Löwis" <martin at v.loewis.de> wrote:

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.

It is impossible to do in general, and I am -1 on any misguided attempts to do so.

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.

No, it's as much about the context as it is the error. We could write our own floating point code that can recover from SIGFPE (which isn't portable, but still mostly doable), but enabling it for arbitrary third-party libraries is completely unsafe.

Printing a stack trace and then aborting would be possible and useful though.

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.

If we could calculate how much stack is left we'd have a much more robust way of doing recursion limits. I suppose this could be done by reading a byte from each page with a temporary SIGSEGV handler installed, but I'm not convinced you can't ask the platform directly somehow. I'd also be considered about thread-safety.

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

-- Adam Olsen, aka Rhamphoryncus

More information about the Python-Dev mailing list