Line 36: | Line 36: | ||
For example, see [https://bugzilla.redhat.com/attachment.cgi?id=369008 this complex backtrace] (relating to [https://bugzilla.redhat.com/show_bug.cgi?id=536786 bug 536786]). | For example, see [https://bugzilla.redhat.com/attachment.cgi?id=369008 this complex backtrace] (relating to [https://bugzilla.redhat.com/show_bug.cgi?id=536786 bug 536786]). | ||
Walking down (numerically) | Walking through the stack frames, going up from the bottom (textually), or down from the top (numerically): | ||
* frames 26 and below show a pygtk application starting up. | * frames 26 and below show a pygtk application starting up. | ||
* An event comes in frame 24/25, and is dispatched into pulsecore (frames 23->18; pstream_packet_callback, pa_context_simple_ack_callback) which: | * An event comes in frame 24/25, and is dispatched into pulsecore (frames 23->18; pstream_packet_callback, pa_context_simple_ack_callback) which: |
Revision as of 01:09, 22 December 2009
Easier Python Debugging
Summary
Owner
- Name: David Malcolm
- Email: <dmalcolm@redhat.com>
Current status
- Targeted release: Fedora 41
- Last updated: (DATE)
- Percentage of completion: XX%
Detailed Description
We ship Python wrappers for numerous libraries implemented in C and C++. Bugs in those libraries and in the usage of those libraries can lead to complicated backtraces from gdb, and it can be hard to figure out what's going on at the python level.
For example, see this complex backtrace (relating to bug 536786).
Walking through the stack frames, going up from the bottom (textually), or down from the top (numerically):
- frames 26 and below show a pygtk application starting up.
- An event comes in frame 24/25, and is dispatched into pulsecore (frames 23->18; pstream_packet_callback, pa_context_simple_ack_callback) which:
- calls a Python callback (down to frame 15),
- ...which invokes python code down to frame 3
- ...where it calls back into native code; whereupon the segfault happens, calling Py_DecRef on some object pointer.
We ship gdbinit in python-devel; copy this to ~/.gdbinit; can then use "pyframe" and other commands to debug things, and figure out where we are in Python code from gdb.
gdb should do this automatically. I plan to hook this in using gdb-archer, and make it automatic:
- Biggest win: automatically display python frame information in PyEval_EvalFrameEx in gdb backtraces, including in ABRT:
- python source file, line number, and function names
- values of locals, if available
- name of function for wrapped C functions