[Python-Dev] Trap SIGSEGV and SIGFPE

Benjamin Peterson musiccomposition at gmail.com
Thu Dec 11 17:38:36 CET 2008


On Thu, Dec 11, 2008 at 10:08 AM, Jeffrey Yasskin <jyasskin at gmail.com> wrote:
> On Thu, Dec 11, 2008 at 1:34 AM, Victor Stinner
> <victor.stinner at haypocalc.com> wrote:
>> But if -as many people wrote-
>> Python is totally broken after a segfault, it is maybe not a good idea :-)
>
> While it's true that after a segfault or unexpected longjmp, there are
> no guarantees whatsoever about the state of the python program, the
> program will often just happen to work, and there are at least some
> programs I've worked on that would rather take the risk in order to
> try to shut down gracefully. For example, an interactive app may want
> to give the user a chance to save her (not necessarily corrupted) work
> into a new file rather than unconditionally losing it. Or a webserver
> might want to catch the segfault, finish replying to the other
> requests that were in progress at the time, maybe reply to the request
> that caused the segfault, and then restart. Yes there's a possibility
> that the events around the segfault exposed some secret internal data
> (and they may do so even without segfaulting), but when the
> alternative is not replying to the users at all, this may be a risk
> the app wants to take. It would be nice for Python to at least expose
> the option so that developers (who are consenting adults, remember)
> can make their own decisions. It should _not_ be on by default, but
> something like sys.dangerous_turn_C_crashes_into_exceptions() would be
> useful.

Trying to recover (or save work etc.) is incredibility unpredictable,
though. It could very well end up making the situation worse!

I'm -1 on putting this in the core.



-- 
Cheers,
Benjamin Peterson
"There's nothing quite as beautiful as an oboe... except a chicken
stuck in a vacuum cleaner."


More information about the Python-Dev mailing list