[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