[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