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:01:29
SpamBayes Score 1.8396396e-13
Marked as misclassified No
Message-id <4D886568.6070100@egenix.com>
In-reply-to <1300761931.13.0.976154105402.issue11393@psf.upfronthosting.co.za>
Content
STINNER Victor wrote:
> 
> STINNER Victor <victor.stinner@haypocalc.com> added the comment:
> 
>> It would be nice if it were enabled by default for fatal errors
>> (and asserts perhaps?).
> 
> That would mean that the module should be a builtin module, or that it is always loaded in memory.
> 
> I am maybe ok to enable it by default for debug builds, but not for release builds. At least, not in a first time.

FWIW: We've been using a similar approach in mxTools.safecall()
(which is an undocumented function only and only available if
mxTools is compiled with a special define; see the mxTools.c source
code for details).

Our use case is different, though: We use this function to
call a Python callable wrapped with a longjump environment and
instead of dumping a traceback we issue an exception, so that
the calling code can deal with the problem in a more flexible way.

The main reasoning here is proper cleanup, signal the problem
to managing code and providing more information about the
interpreter state at the time of the segfault.

The function is mostly used when calling out to (possibly buggy)
3rd party extensions hooked into a long running web server
application, where it enables the server process to write
request information about the problem to a log file and then
shuts down the process very quickly.

Note that we haven't bothered dealing with threads, since we
normally use single threaded server processes and because signals
and threads don't interact reliably anyway.

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.

BTW: Why do you call the traceback functions "*backtrace*" instead
of "*traceback*" ?

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:01:31lemburgsetrecipients: + lemburg, pitrou, vstinner, Arfrever, Trundle, dmalcolm
2011-03-22 09:01:30lemburglinkissue11393 messages
2011-03-22 09:01:29lemburgcreate