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:

(gdb) py-bt
#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.

4 Answers 4


Here's the problem: to have access to debugging symbols in GDB, you must invoke a different binary: "python-dbg" instead of "python" (found this in /usr/share/doc/python2.7-dbg/README.debug).


On Ubuntu 16.04 I managed to get Python stack trace in Python 3.5 by:

  1. Installing python3-dbg and python3-dev:

    $ sudo apt install python3-dbg python3-dev

    python3-dbg package comes with short documentation how to use it in /usr/share/doc/python3-dbg/README.debug which I will use in the next step.

  2. Appending unpacked GDB helper script /usr/share/doc/python3.5/gdbinit.gz to ~/.gdbinit:

    zcat /usr/share/doc/python3.5/gdbinit.gz >> ~/.gdbinit

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.
(gdb) py-bt
Traceback (most recent call first):
  File "/usr/bin/indicator-cpufreq", line 80, in <module>
  • my gdbinit.gz on Ubuntu 16.04 contains many commands like pystack but there is no py-bt. Any idea what's going on?
    – Anton
    Aug 24, 2018 at 22:45
  • Why is python 3.5 even though I have already installed python 3.6 ?
    – skytree
    Mar 2, 2019 at 6:27

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.

With all this in place, I managed to debug the SIGSEGV I was running into: https://bugs.python.org/issue34870

  • how can we use python2.7-dbg
    – Nathan B
    Dec 4, 2022 at 13:16
  • @NathanB Use gdb /usr/bin/python2.7-dbg --args yourscript.py to start it (note, the binary is probably python3-dbg these days, coming from the python3-dbg package). Then, place breakpoints (inside the Python interpreter) and use run to to start the interpreter in debug mode. For more GDB documentation, use e.g. sourceware.org/gdb/onlinedocs/gdb Dec 5, 2022 at 19:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.