Come posso ottenere informazioni sulla traccia dello stack di Python usando GDB?

11

Sto usando GDB per eseguire il debug di un errore di segmentazione nella mia applicazione Python su Kubuntu 12.04. Presumibilmente GDB versione 7 ha macro integrate per l'estrazione di informazioni sullo stack di Python (http://docs.python.org/devguide/gdb.html), ma ho problemi a farlo funzionare. Ho installato python-dbg.

Quando chiedo una traccia dello stack di Python in GDB, il risultato è simile al seguente:

(gdb) py-bt
#5 (unable to read python frame information)
#16 (unable to read python frame information)
#26 (unable to read python frame information)
...

La mia versione GDB è 7.4-2012.04-0ubuntu2, Python è 2.7.3-0ubuntu3.

python gdb

— Luca
fonte

16

Ecco il problema: per avere accesso ai simboli di debug in GDB, devi invocare un altro binario: "python-dbg" invece di "python" (trovato in /usr/share/doc/python2.7-dbg/README.debug ).

— Luca
fonte

1

Sorprendendo come questo non sia menzionato in fedoraproject.org/wiki/Features/EasierPythonDebugging o in qualsiasi altra parte che ho potuto trovare. Grazie Luca.

— Quimnuss,

Questo non è vero. Devi solo ottenere simboli di debug che corrispondano al pitone che stai utilizzando. Possono esserci dei gotcha se si ha a che fare con un virtualenv poiché quel python potrebbe non corrispondere al python del proprio sistema. C'è un grande resoconto su podoliaka.org/2016/04/10/debugging-cpython-gdb

— aggieNick02

6

Su Ubuntu 16.04 sono riuscito a ottenere la traccia dello stack Python in Python 3.5:

Installazione python3-dbge python3-dev:

$ sudo apt install python3-dbg python3-dev

python3-dbgIl pacchetto include una breve documentazione su come usarlo, /usr/share/doc/python3-dbg/README.debugche userò nel prossimo passaggio.
Aggiunta dello script helper GDB non compresso /usr/share/doc/python3.5/gdbinit.gza ~/.gdbinit:

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

Ora gdb sarà in grado di trovare simboli per il binario Python e py-btfunziona per visualizzare la traccia dello stack Python 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:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
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>
    Gtk.main()
(gdb)

— rutsky
fonte

my gdbinit.gz su Ubuntu 16.04 contiene molti comandi simili pystackma non ce n'è py-bt. Qualche idea di cosa stia succedendo?

— Anton,

Perché python 3.5anche se ho già installato python 3.6?

— skytree

0

Forse questo aiuta qualcuno: il binario è chiamato python2.7-dbgsul mio sistema Debian, proveniente dal python2.7-dbgpacchetto. Ho anche installato il python2.7-devpacchetto e apt-get source python2.7-dbg, in modo da gdbpoter trovare i file di origine nell'interprete Python.

Con tutto questo in atto, sono riuscito a eseguire il debug di quello SIGSEGVche stavo incontrando: https://bugs.python.org/issue34870

— Per Lundberg
fonte