claims of python unit test un-debugability considered somewhat exaggerated

[David Ostrovsky]

On Tue, 2013-04-09 at 11:26 -0400, David Malcolm wrote:
> On Tue, 2013-04-09 at 11:22 +0100, Michael Meeks wrote:
> > Hi guys,
> > 
> > On Mon, 2013-04-08 at 11:32 -0600, Tom Tromey wrote:
> > > CCing David Malcolm.
> > > 
> > > Michael> (gdb) py-bt
> > > 
> > > I just wanted to mention here that Phil Muldoon is working on a
> "frame
> > > filter" patch series that is basically "pretty printing for stack
> > > frames".  With this in place you'll no longer need a special
> command --
> > > with appropriate support from Python, you'll be able to see
> interpreted
> > > frames interleaved with the low-level C frames.
> > 
> >       Oh - nice ! :-)
> > 
> > > This series is nearing final review now and should appear in gdb
> 7.7,
> > > later this year.
> > 
> >       Excellent news indeed.
> > 
> > > I think we're planning to rewrite the existing "py-bt" code into
> frame
> > > filter form ourselves.
> > 
> >       So - in which case this significantly reduces the problems of
> using
> > python for debugging; I assume that with py-bt - there are still
> issues
> > with interleaving two tools for printing parts of backtraces when we
> > call several times to and fro between C++ and python.
> > 
> > > Eventually we'd like to have more full support for "mixed"
> interpreter
> > > and C debugging.  However this is a ways off.
> > 
> >       For me, clearly seeing the python line numbers is the key
> rather than
> > the interpreter details - we treat python itself as working
> black-box -
> > and the script itself as the problem ;-)
> 
> Aha.  Sorry; I came into this discussion halfway though.
> 
> I wrote the Python gdb hooks for CPython itself (i.e. "py-bt" and
> others).  You can see documentation for them here:
> 
> http://docs.python.org/devguide/gdb.html#gdb-7-and-later
> 
> In particular:
>   (gdb) py-list
> should give you python source code for the current python frame.
>         

Works like a charm here on OpenSUSE 12.3 too, with system python3.3:

(gdb) py-list
  32                )
  33    
  34        # property 'Value' is read only?
  35        @unittest.expectedFailure
  36        def test_get_expression_veto_read_only(self):
 >37            os.kill(os.getpid(), signal.SIGUSR1)

and

(gdb) py-bt
Traceback (most recent call first):
  File "./qa/unoapi/python/get_expression.py", line 37, in
test_get_expression_veto_read_only
    os.kill(os.getpid(), signal.SIGUSR1)
  File "/usr/lib64/python3.3/unittest/case.py", line 96, in wrapper
    func(*args, **kwargs)


I must be missing something, but i didn't find a standard way how to
install Tools/gdb/libpython.py from cpython, so i just cloned the
upstream python, with 
hg clone http://hg.python.org/cpython

and borrowed that lib from there (sourcing it manually on gdb):
cpython/Tools/gdb/libpython.py

I wrote a detailed summary on wiki:

https://wiki.documentfoundation.org/Development/Python_Unit_Tests

Enjoy the first backtrace from "in-process python unit test" ;-)

David