I am using GDB to debug a segmentation fault in my python application on Kubuntu 12.04.
Supposedly GDB version 7 has built-in macros for extracting information about the python stack (http://docs.python.org/devguide/gdb.html), but I am having trouble getting it to work. I have installed python-dbg.
When I ask for a python stack trace in GDB, the result looks like this:
#5 (unable to read python frame information)
#16 (unable to read python frame information)
#26 (unable to read python frame information)
My GDB version is 7.4-2012.04-0ubuntu2, Python is 2.7.3-0ubuntu3.
Now gdb will be able to find symbols for Python binary and py-bt works for displaying Python stack trace in gdb:
$ gdb -p 4762
GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.04) 7.11.1
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
Find the GDB manual and other documentation resources online at:
For help, type "help".
Type "apropos word" to search for commands related to "word".
Attaching to process 4762
[New LWP 4852]
[New LWP 4853]
[New LWP 4854]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0x00007f38e43deb5d in poll () at ../sysdeps/unix/syscall-template.S:84
84 ../sysdeps/unix/syscall-template.S: No such file or directory.
Traceback (most recent call first):
File "/usr/bin/indicator-cpufreq", line 80, in <module>
Sometimes, it is not possible to get debuginfo; for example if you are using conda Python, these packages do not come with debuginfo. It turns out that py-spy (https://github.com/benfred/py-spy) has a more robust implementation of Python backtrace dumping that doesn't rely on having accurate debug symbols available. However, as it also uses ptrace, you will have to detach gdb first. Here's how to make it work:
Do your thing in gdb, getting to the breakpoint you want to get the Python backtrace for.
Make gdb pass through SIGSTOP with handle SIGSTOP noprint nostop pass
Pause the process with signal SIGSTOP
Detach gdb with detach. Note the PID
Run py-spy dump --pid $PID in another terminal. This gives you your backtrace.
You can keep running gdb with attach $PID. Note that you can continue the process even if it is SIGSTOP'ed and it will run as normal, and will continue to be paused if you detach again
Maybe this helps someone: The binary is named python2.7-dbg on my Debian system, coming from the python2.7-dbg package. I also installed the python2.7-dev package and apt-get source python2.7-dbg, so that gdb could find the source files to the Python interpreter.