Message124527
Version 11 of my patch:
- Disable the fault handler (and displaying the backtrace on a fatal error) by default
- The fault handle can be enabled by setting the PYTHONFAULTHANDLER environment variable or using "-X faulthandler" command line option (instead of being disabled by setting the PYTHONNOFAULTHANDLER env var)
- Use PyGILState_GetThisThreadState() instead of _Py_atomic_load_relaxed(&_PyThreadState_Current) to get the state of the current thread, especially if the current thread doesn't hold the GIL
- Add a protection against recursive calls to _Py_DisplayBacktrace() (a recursive call does nothing), even it is very unlikely
- Don't repeat the exception message after the backtrace
- Add a test on a segfault in a thread not holding the GIL
Disable the fault handler by default solves many issues reported on the python-dev mailing list:
- Issues with embedded Python
- Python 3.2 beta 2 is released
- The fault handler supposes that the file descriptor 2 is the standard error output, but it may be a critical file or a network socket
Amaury asked for a sys.setsegfaultenabled() option: I think that the command line option and the environment variable are enough. The question is now how to enable the feature for a single run (reproduce a crash to try to get more information), not how to enable/disable it system-wide (because most developers agree that it should be disabled by default).
Should it be backported to Python 2.7 and 3.1? |
|
Date |
User |
Action |
Args |
2010-12-23 01:52:21 | vstinner | set | recipients:
+ vstinner, amaury.forgeotdarc, davidfraser, scott.dial, pitrou, dmalcolm, joshbressers |
2010-12-23 01:52:21 | vstinner | set | messageid: <1293069141.78.0.0338938839056.issue8863@psf.upfronthosting.co.za> |
2010-12-23 01:52:17 | vstinner | link | issue8863 messages |
2010-12-23 01:52:17 | vstinner | create | |
|