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

Stefan Krah stefan at bytereef.org
Mon Dec 20 17:56:32 CET 2010

Victor Stinner <vstinner at edenwall.com> wrote:

Le lundi 20 décembre 2010 15:55:57, Stefan Krah a écrit : > > 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.

The fault handler helps developers because they don't have to have a Python compiled in debug mode and to run the application in a debugger (like gdb). If the developer is unable to reproduce an error, because it's an Heisenbug, or because the developer doesn't have the same OS, libraries and/or applications, the fault handler helps the developer to isolate the problem.

This is what I'm sceptical about. I think the tracebacks are don't carry enough information for that.

Any bug report which only contain "Segmentation fault" information. But I cannot give you a revelant example because users are too shy to report an issue if they don't have more information than just "the program crashed". With a fault handler displaying the Python backtrace, I hope that more users will report bugs.

I wonder. It would be fine to make the tracebacks optional and tell the user to rerun the program with the proper environment variable set.

> I did use version 10. I've verified the same behavior with a fresh py3k > checkout and this 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.

What is your OS (name, version)? I only tested crashers on Linux (Debian Sid).

Ubuntu 8.10, 64-bit, real hardware.

I also tested on FreeBSD-8.0-qemu:

$ ./python Lib/test/crashers/compiler_recursion.py Illegal instruction: 4 (core dumped)

$ ./python Lib/test/crashers/nasty_eq_vs_dict.py [hanging with no output]

Stefan Krah

More information about the Python-Dev mailing list