Inferior python debugging: working prototype

Inferior python debugging: working prototype

[David Malcolm]

(This is a followup to this December posting:
http://sourceware.org/ml/archer/2009-q4/msg00129.html "Pretty-printing
backtraces when "python" is the inferior process")

I've now got working gdb python code for prettyprinting the various
types seen when the inferior process is linked against libpython, such
as for debugging the python binary itself (or presumably a build of gdb
itself, though I haven't tried that).

I am still seeing the issue described in that post where variables of
interest are visible from within the regular (gdb) interface, but not
visible from python's gdb.selectedframe.read_var() (specifically, the
PyFrameObject *f within PyEval_EvalFrameEx; which appears to be an issue
with an inlined frame of C code).

Having said that, I noticed that the backtrace contained this data, and
by writing a prettyprinter rather than a backtrace implementation I'm
able to hook in to the gdb.Value and sidestep this issue.

Current status:
  - I've written a libpython.py which can be seen in this 1-file git
repository:
http://fedorapeople.org/gitweb?p=dmalcolm/public_git/libpython.git;a=summary
  - the code has a prettyprinter for (PyObject*) and for
(PyFrameObject*)
  - the code has to be imported manually
  - It works, and generates large amounts of useful debugging
information, showing (nested) lists, tuples, ints, strings, unicode,
old-style classes etc, and showing file/line/locals/globals information
at the python level; it seems somewhat robust in the face of corrupt
data in the inferior process.
  - See:
https://fedoraproject.org/wiki/Features/EasierPythonDebugging#User_Experience
for a series of text dumps comparing before/after backtraces of a
segfault within /usr/bin/python.
  - It mostly works with python3 as well.
  - All my testing has been by hand, using Fedora 12's build of gdb
(gdb-7.0.1-26.fc12.i686)

Questions:
  - I want the prettyprinter hooks to be used by default on Python
backtraces in Fedora 13, so that (for example) automated tools that
capture backtraces contain this rich debugging information. What's the
best way of wiring this up so that the module is imported?  Is something
like this happening for the GLib/GTK hooks, or for the STL?
  - should this be distributed as part of gdb or part of python?  (it
handles both python2 and python3, mostly, at any rate)
  - I'd like to be able to automatically test this.  Am I right in
thinking that it's reasonable to assume that given that a gdb configured
with --with-python can also be tested debugging that instance of python
(I'd also like to automate testing of python3 support, which would be a
different runtime)
  - to what extent is a pretty-printer expected to return in a sane
amount of time and use sane amounts of RAM?  For example, if my
prettyprinter tries to print a PyListObject, but the length of the list
(the "ob_size" field) has become  0xdeadbeef rather than, say 3,
building a proxy list to represent it within the gdb process is probably
going to make gdb run out of heap.  Are there any standards around this?
(e.g. some defined limit to how much it's worth scraping)

Hope this is useful
Dave

Re: Inferior python debugging: working prototype

[Tom Tromey]

David> I've now got working gdb python code for prettyprinting the various
David> types seen when the inferior process is linked against libpython, such
David> as for debugging the python binary itself (or presumably a build of gdb
David> itself, though I haven't tried that).

Very cool.

David> I am still seeing the issue described in that post where variables of
David> interest are visible from within the regular (gdb) interface, but not
David> visible from python's gdb.selectedframe.read_var() (specifically, the
David> PyFrameObject *f within PyEval_EvalFrameEx; which appears to be an issue
David> with an inlined frame of C code).

Could you file this in bugzilla?  If it works from the CLI then there
should be some way to access it from Python.

David>   - I want the prettyprinter hooks to be used by default on Python
David> backtraces in Fedora 13, so that (for example) automated tools that
David> capture backtraces contain this rich debugging information. What's the
David> best way of wiring this up so that the module is imported?  Is something
David> like this happening for the GLib/GTK hooks, or for the STL?

See the Auto-loading and Selecting Pretty-Printers nodes in the manual.
I think they describe it fairly well.

The libstdc++ printers are all set up to work this way.  If you read the
libstdc++ "hook file", it is full of a lot of goo you may not need,
because upstream GCC wants its install tree to be relocatable.  If you
don't care about that you can shrink the file down to a couple of lines.

David>   - should this be distributed as part of gdb or part of python?  (it
David> handles both python2 and python3, mostly, at any rate)

Ideally, IMO, with Python.  In general I think the only way to scale
this up to lots of libraries is to maintain the custom code alongside
its project.

Right now, in Fedora, we are distributing the libstdc++ printers in the
gdb RPM, but I think (hope) we will be changing that.  I don't really
remember the detailed reason for this decision, but basically it was
expediency.

David>   - I'd like to be able to automatically test this.  Am I right in
David> thinking that it's reasonable to assume that given that a gdb configured
David> with --with-python can also be tested debugging that instance of python
David> (I'd also like to automate testing of python3 support, which would be a
David> different runtime)

I'm not sure I understand the potential issue.

There should be no problem using python-enabled gdb with these printers
to debug a second instance of itself, or of any other program using
python.

David>   - to what extent is a pretty-printer expected to return in a
David> sane amount of time and use sane amounts of RAM?

What I recommend is trying to write your printers so that they work
lazily.  That is, don't precompute the proxy objects, have your
printer's children method return an iterator that computes them lazily.

GDB will only ask for the children it intends to print, as determined
either by user settings in the CLI (e.g., "set print elements") or by UI
requests to limit the number of varobj children in MI.

This may not always be easy; if it really isn't possible I am not sure
what you could do.  The problem is that if your printer limits the
output, there is no way to request more.

Tom