Issue #1204 open

gdb hooks for debugging PyPy

David Malcolm
created an issue

From (

Comments (6)

  1. David Malcolm reporter

    gdb 7 onwards is scriptable using an embedded CPython 2.*, giving the ability to write fragments of Python to add new commands, and to tell gdb how to pretty-print data, etc. (A couple of years ago I wrote such code to make it easier to debug CPython; see )

    I'm attaching a script I've written to help debug PyPy. It's a work in progress so far, but it's able to print RPython strings, and some PyPy frame information.

    For example, if I run $ gdb --eval-command="break pypy_g_PyFrame_run" --eval-command="run" --args pypy I get this output when the breakpoint is hit: Breakpoint 1, pypy_g_PyFrame_run (l_self_11960=Frame for at interpreter_pyframe.c:48

    Note how the frame object has been pretty-printed as "Frame for"

    I'm attaching what a full backtrace looks like with these hooks for a pypy process waiting at the interactive prompt (full-backtrace.txt): numerous frames are visible. Unfortunately, many values are optimized out, though.

    Of course this code is specific to the C backend, and it's probably sensitive to translation options - but my feeling is that every little helps when debugging the generated C code.

    FWIW I've been developing this on a Fedora 17 x86_64 box, using the pypy rpms (which have slightly non-standard translation options; see;a=blob;f=pypy.spec ).

    I copy the file to: /usr/lib/debug/usr/lib64/pypy-1.9/ alongside the DWARF data (where I've been editing it in place).

    gdb will load this on startup when debugging /usr/lib64/pypy-1.9/pypy (aka /usr/bin/pypy). My plan is to package this file within my rpms so that it's within the debuginfo rpm (I do something similar for CPython on Fedora/RHEL).

    Presumably this file should live somewhere in the pypy source tree (where?) Should I create a branch on bitbucket, and hack on it there?

  2. David Malcolm reporter

    Motivation: although PyPy's generated C code may be perfect, as soon as you link 3rd-party code into the process (e.g. via extension modules, ctypes, or some other FFI), the process runs the risk of crashes induced by bugs in that 3rd party code. Hence it's useful to have some way of debugging the process and figuring out e.g. what thread is doing what. (For example: pointers getting freed by 3rd party code that shouldn't have freed them, refcounting bugs in extension modules, random pointer corruption, etc etc)

  3. Log in to comment