[Python-Dev] Issue #8863 adds a new PYTHONNOFAULTHANDLER?environment variable (original) (raw)

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/gcinspection.py > (<object object at 0x7f01827ad870>, , , , , , > , , , ) Fatal Python error: Segmentation fault > > Traceback (most recent call first): > File "Lib/test/crashers/gcinspection.py", line 29 in g > File "Lib/test/crashers/gcinspection.py", line 32 in > 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