[Python-Dev] Issue #8863 adds a new PYTHONNOFAULTHANDLER environment variable (original) (raw)
Victor Stinner victor.stinner at haypocalc.com
Sun Dec 19 23:32:03 CET 2010
- Previous message: [Python-Dev] Issue #8863 adds a new PYTHONNOFAULTHANDLER environment variable
- Next message: [Python-Dev] Issue #8863 adds a new PYTHONNOFAULTHANDLER environment variable
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Le samedi 18 décembre 2010 à 13:55 -0500, Alexander Belopolsky a écrit :
I am -1 on the feature as written. I would be -0 if it did not install signal handlers by default and even better was implemented in a separate module, not in core.
I think that the feature is useless if it is disabled by default. How do you know that you application will crash? The idea is to give informations to the user when an application crashs: the user can use the backtrace or send it to the developer. Segmentation faults are usually not (easilly) reproductible :-( So even if you enable the fault handler, you may not be able to replay the crash. Or even worse, the fault may not occurs at all when you enable the fault handler... (Heisenbugs!)
This feature is similar to the one that is implemented by R and with R, it was always a problem when R was embedded as a library.
Which kind of problem? A conflict with an existing fault handler?
It has always been a welcome feature of Python that its core did not mess with the application global state.
What do mess the application global state?
Before this is approved, I would like to see a discussion of the consequences for embedded Python
I suppose that if a fault occurs outside Python, the fault handler displays an irrevelent or empty Python backtrace.
The fault handler is installed by Py_InitializeEx(), and uninstalled by Py_Finalize().
If the program has its own fault handler or doesn't want Python fault handler, it can set PYTHONNOFAULTHANDLER environment variable. Should we add a C function to the Python API to configure (disable) the fault handler?
I only know two applications catching faults: Mplayer and aMule. I don't think that they embed Python. If they do, I think that these two applications can do something special. Since there are only two applications having their own fault handler, I don't think that we should disable the fault handler by default.
(System wide fault handler, like Apport on Ubuntu, can be configured system wide by setting the PYTHONNOFAULTHANDLER environment variable)
and particularly for the case when there are multiple interpreters in the same process.
What? Is it a myth or does Python really support multiple interpreters in the same process? How is it possible? Who uses this?
_Py_DumpBacktrace() function (of my patch) uses _Py_atomic_load_relaxed(&_PyThreadState_Current) to get the current thread state. I picked up this instruction from PyThreadState_Get(). If it doesn't work, PyThreadState_Get() should be fixed too.
Victor
- Previous message: [Python-Dev] Issue #8863 adds a new PYTHONNOFAULTHANDLER environment variable
- Next message: [Python-Dev] Issue #8863 adds a new PYTHONNOFAULTHANDLER environment variable
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]