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

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