Victor Stinner <vstin...@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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
