[Python-Dev] Issue #8863 adds a new PYTHONNOFAULTHANDLER environment variable
Stefan Krah
stefan at bytereef.org
Mon Dec 20 12:08:35 CET 2010
Alexander Belopolsky <alexander.belopolsky at gmail.com> wrote:
> On Sat, Dec 18, 2010 at 11:50 AM, Georg Brandl <g.brandl at gmx.net> wrote:
> ..
> > In any case, this is coming pretty late; beta 2 is scheduled for this
> > weekend, and even if this is something that only kicks in when all hope
> > is lost anyway, it is a new feature. I should like to hear approval
> > from a few more devs before I will let this go into 3.2.
> >
>
> 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 would not want this to be the default either. I think the output
is not particularly informative:
$ ./python Lib/test/crashers/gc_inspection.py
(<object object at 0x7f01827ad870>, <NULL>, <NULL>, <NULL>, <NULL>, <NULL>, <NULL>, <NULL>, <NULL>, <NULL>)
Fatal Python error: Segmentation fault
Traceback (most recent call first):
File "Lib/test/crashers/gc_inspection.py", line 29 in g
File "Lib/test/crashers/gc_inspection.py", line 32 in <module>
Segmentation fault
Segmentation fault
Another test is hanging indefinitely (Ubuntu 64-bit):
$ ./python Lib/test/crashers/nasty_eq_vs_dict.py
[hanging with no output]
It's hard to get signal handlers right across multiple platforms; even
SIGINT catching does not work properly on OpenBSD:
http://bugs.python.org/issue8714
In short, I agree that having more signal handlers by default is not a
good idea.
Stefan Krah
More information about the Python-Dev
mailing list