This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author poolie
Recipients BreamoreBoy, Rhamphoryncus, belopolsky, docs@python, eric.araujo, georg.brandl, gvanrossum, poolie, schmir, tebeka, terry.reedy, vstinner
Date 2011-08-31.00:52:00
SpamBayes Score 1.52935e-07
Marked as misclassified No
Message-id <>
In-reply-to <>
On 31 August 2011 07:56, STINNER Victor <> wrote:
> STINNER Victor <> added the comment:
>> def handler(signal, stackframe):
>>     print "OUCH"
>>     stdout.flush()
>>     _exit(1)
> What do you want to do on a SIGSEGV? On a real fault, you cannot rely on  Python internal state, you cannot use any Python object. To handle a real SIGSEGV fault, you have to implement a signal handler using only *signal safe* functions.... in C.

Well, strictly speaking, it is very hard or impossible to write C code
that's guaranteed to be safe after an unexpected segv too; who knows
what might have caused it.  The odds are probably better that it will work in
in C than in Python.  At any rate I think it's agreed that the
original code is not supported and it's just the docs that need to

So what do you think of
<> ?
Date User Action Args
2011-08-31 00:52:01pooliesetrecipients: + poolie, gvanrossum, georg.brandl, terry.reedy, tebeka, belopolsky, Rhamphoryncus, vstinner, schmir, eric.araujo, docs@python, BreamoreBoy
2011-08-31 00:52:00poolielinkissue1215 messages
2011-08-31 00:52:00pooliecreate