On Mon, 20 Dec 2010 15:55:57 +0100, Stefan Krah <ste...@bytereef.org> wrote: > Victor Stinner <vstin...@edenwall.com> wrote: > > Stefan Krah wrote: > > > 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?
How is 'line 29 in g' not more precise than 'Segmentation fault'? Now imagine that this error is being produced from a 20,000 line application program bundle... -- R. David Murray www.bitdance.com _______________________________________________ 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