[Python-Dev] Trap SIGSEGV and SIGFPE

[Adam Olsen]

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