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 lemburg
Recipients Arfrever, Trundle, dmalcolm, lemburg, pitrou, vstinner
Date 2011-03-22.09:36:22
SpamBayes Score 2.463585e-13
Marked as misclassified No
Message-id <4D886D95.5050709@egenix.com>
In-reply-to <1300785892.17117.3.camel@marge>
Content
STINNER Victor wrote:
> 
> STINNER Victor <victor.stinner@haypocalc.com> added the comment:
> 
> Le mardi 22 mars 2011 à 09:01 +0000, Marc-Andre Lemburg a écrit :
>> Perhaps you could consider adding a similar approach (raising
>> an exception instead of writing a traceback) to the module.
>> We could then port our code to use your module, which is
>> more advanced.
> 
> I already wrote a patch implementing this idea, 2 years ago, and the
> idea was rejected. Re-read the history of the module, described in the
> first message of this issue:
> 
> << History of this module.
> 
> I first proposed a segfault handler using setjmp/longjmp to raise a
> classic Python exception. So it was  possible to execute Python code
> after a segfault (including stack overflow). But the idea was rejected
> because the Python internal state may be corrupted if the segfault was
> an invalid memory write (buffer overflow?), and anyway we cannot
> warranty that the internal state is still consistent after a long jump.
> 
> => http://bugs.python.org/issue3999 (sept. 2009)
> 
> ... >>
> 
> You may dig python-dev archives to learn more about this proposition.

I know that the state after a longjump in such a case cannot
be guaranteed, but from using the approach in practice over many
years, I know that it works quite well - most situations related
to programming errors in the 3rd party modules we plug into the
system (quant libs, ie. code that does pricing and risk analysis
of financial products) are segfaults related to NULL pointer
derefs and division by zero. Complete corruption of the Python
interpreter state is very rare.

Anyway, providing such an approach as option (with the default
being your implemented traceback printout), would leave the
decision to take this risk to the programmer and I think that's
a fair deal.

>> BTW: Why do you call the traceback functions "*backtrace*" instead
>> of "*traceback*" ?
> 
> Oh... I don't know. Since Python uses "traceback" word, I will rename my
> functions.

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/
History
Date User Action Args
2011-03-22 09:36:26lemburgsetrecipients: + lemburg, pitrou, vstinner, Arfrever, Trundle, dmalcolm
2011-03-22 09:36:22lemburglinkissue11393 messages
2011-03-22 09:36:22lemburgcreate