[Python-Dev] Issue #8863 adds a new PYTHONNOFAULTHANDLER?environment variable

Stefan Krah stefan at bytereef.org
Mon Dec 20 15:55:57 CET 2010


Victor Stinner <vstinner at edenwall.com> wrote:
> Le lundi 20 décembre 2010 12:08:35, Stefan Krah a écrit :
> > 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
> 
> The backtrace is valid. Don't you think that this backtrace is more useful 
> than just "Segmentation fault"?

Perhaps I misunderstood, but I thought the purpose of the patch was to
let developers act more quickly on bug reports. I wonder if this output
really speeds up the process.

Do you have an example bug where this patch helps in finding the precise
location of a segfault?


> Patch version 9 doesn't call the previous handler. Please retry with patch 
> version 10 (which call the previous handler).

I did use version 10. I've verified the same behavior with a fresh py3k
checkout and this patch:

$ md5sum segfault_handler-10.patch
e1b5a9439d2b51d0a63f701dd694796d  segfault_handler-10.patch


My machine currently has a load average of 2. Perhaps you'll be able to
reproduce it if you crank up the load average.



Stefan Krah




More information about the Python-Dev mailing list