使用 gdb 7 对调试 Python 程序的支持需要什么? [英] What is needed to use gdb 7's support for debugging Python programs?

问题描述

我想使用 gdb 7 的支持来调试 Python劣质进程".

我需要什么才能做到这一点?

例如:

• 运行劣质 Python 的配置脚本需要使用哪些标志?

• 低级 Python 进程是否必须是 Python 2.7 或更高版本(我看到那是 Python 源代码树中的 gdb 支持的部分提交的时候)?还是只有 gdb 进程本身需要 Python 2.7?

• 需要安装哪些文件可能不会被所有发行版打包?例如，在 packages.ubuntu.com 上我没有得到任何关于 python-gdb.py 的点击，我认为这是需要的.

了解特定发行版的需求会非常方便.我对 Ubuntu 和 Centos 的需求特别感兴趣.

解决方案

Python好像需要用--with-pydebug编译(在Ubuntu 12.04上，包python-dbg 包含一个合适的 Python 可执行文件，它本身称为 python-dbg).劣质的 Python 不需要是 Python 2.7 -- 2.6 可以成功加载 2.7 gdb 扩展(请参阅下面的调试会话).至少在 Ubuntu 12.04 上，安装的定义 gdb 扩展的文件称为 libpython.py，而不是 python-gdb.py(出于某种原因，构建 Python 会产生包含这两个文件的构建目录——它们是相同的).

但是，我认为目前无法使用生产核心文件进行调试:看起来 Python 劣等进程的 gdb 扩展试图获取在生产二进制文件中得到优化的变量(例如，fPyEval_EvalFrameEx 中的变量).似乎 Linux/gdb 和 Python 尚未达到在 Illumos 上实现 JavaScript 的出色水平，Bryan Cantrill 在这里报告说能够以这种方式调试生产核心转储:

http://www.infoq.com/presentations/Debugging-Production-Systemsp>

这是 Ubuntu 12.04 上的调试会话，显示 gdb 使用 Python 2.7 的 gdb 扩展运行 Python 2.6 次等进程来调试段错误.首先是导致段错误的代码:

~/Downloads/Python-2.6.4$ cat ~/bin/dumpcore.pyFoo类:定义栏(自我):从 ctypes 导入 string_atstring_at(0xDEADBEEF) # 此代码将导致 Python 出现段错误定义主():f = Foo()f.someattr = 42f.someotherattr = {'one':1, 'two':2L, 'three':[(), (None,), (None, None)]}f.bar()如果 __name__ == "__main__":主要的()

和调试会话:

~/Downloads/Python-2.6.4$ gdb --args ./python ~/bin/dumpcore.pyGNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04版权所有 (C) 2012 Free Software Foundation, Inc.许可证 GPLv3+:GNU GPL 版本 3 或更高版本 <http://gnu.org/licenses/gpl.html>这是免费软件:您可以自由更改和重新分发它.在法律允许的范围内，不提供任何保证.输入显示复制"和显示保修"了解详情.此 GDB 配置为x86_64-linux-gnu".有关错误报告说明，请参阅:<http://bugs.launchpad.net/gdb-linaro/>...从/home/john/Downloads/Python-2.6.4/python...读取符号...完成.(gdb) 运行启动程序:/home/john/Downloads/Python-2.6.4/python/home/john/bin/dumpcore.py[启用使用 libthread_db 进行线程调试]使用主机 libthread_db 库/lib/x86_64-linux-gnu/libthread_db.so.1".程序收到信号 SIGSEGV，分段错误.0x0000000000468d67 in PyString_FromString (str=0xdeadbeef <Address 0xdeadbeef out of bounds>) at Objects/stringobject.c:116116 大小 = strlen(str);(gdb) py-bt未定义的命令:py-bt".试试帮助".(gdb) 蟒蛇>导入系统>sys.path.insert(0, "/home/john/Downloads/Python-2.7/Tools/gdb")>导入 libpython>(gdb) py-bt#10 帧 0x8f0f90，用于文件/home/john/Downloads/Python-2.6.4/Lib/ctypes/__init__.py，第 496 行，在 string_at 中(ptr=3735928559，size=-1)返回 _string_at(ptr, 大小)#14 帧 0x8ebf90，用于文件/home/john/bin/dumpcore.py，第 5 行，in bar (self=<Foo(someattr=42, someotherattr={'three': [(), (None,),(None, None)], 'two': 2L, 'one': 1}) 在远程 0x7ffff6e03240>, string_at=)string_at(0xDEADBEEF) # 此代码将导致 Python 出现段错误#17 帧 0x8ebd80，用于文件/home/john/bin/dumpcore.py，第 12 行，在 main (f=<Foo(someattr=42, someotherattr={'three': [(), (None,),(None, None)], 'two': 2L, 'one': 1}) 在远程 0x7ffff6e03240>)f.bar()#20 帧 0x8eb680，用于文件/home/john/bin/dumpcore.py，第 16 行，在 <module>()主要的()(gdb)

I'd like to use gdb 7's support for debugging Python "inferior processes".

What do I need to be able to do that?

For example:

• What flags does the inferior Python's configure script need to have been run with?

• Does the inferior Python process have to be Python 2.7 or newer (I see that's when the part of the gdb support for this that's in Python source tree was committed)? Or is Python 2.7 only needed by the gdb process itself?

• What files need to have been installed that might not be packaged by all distributions? For example, on packages.ubuntu.com I don't get any hits for python-gdb.py, which I believe is needed.

It would be very handy to know what's needed on particular distributions. I am particularly interested in what's needed for Ubuntu and Centos.

解决方案

Python seems to need to have been compiled with --with-pydebug (on Ubuntu 12.04, package python-dbg contains a suitable Python executable, itself called python-dbg). The inferior Python does not need to be Python 2.7 -- 2.6 loads the 2.7 gdb extensions successfully (see the debugging session below). At least on Ubuntu 12.04, the file that gets installed that defines the gdb extensions is called libpython.py, not python-gdb.py (for some reason, building Python yields a build directory containing both those files -- they are identical).

However, I don't think it's currently possible to debug using production core files: it looks like the gdb extensions for Python inferior processes try to get hold of variables that get optimized away in a production binary (for example, the f variable in PyEval_EvalFrameEx). It seems Linux / gdb, and Python has yet to reach the level of awesomeness achieved for JavaScript on Illumos which Bryan Cantrill reports here is able to debug production core dumps in this way:

http://www.infoq.com/presentations/Debugging-Production-Systems

Here's the debug session on Ubuntu 12.04 showing gdb running a Python 2.6 inferior process to debug a segfault, using Python 2.7's gdb extensions. First the code to cause the segfault:

~/Downloads/Python-2.6.4$ cat ~/bin/dumpcore.py
class Foo:

    def bar(self):
        from ctypes import string_at
        string_at(0xDEADBEEF) # this code will cause Python to segfault


def main():
    f = Foo()
    f.someattr = 42
    f.someotherattr = {'one':1, 'two':2L, 'three':[(), (None,), (None, None)]}
    f.bar()


if __name__ == "__main__":
    main()

and the debugging session:

~/Downloads/Python-2.6.4$ gdb --args ./python ~/bin/dumpcore.py
GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04
Copyright (C) 2012 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".
For bug reporting instructions, please see:
<http://bugs.launchpad.net/gdb-linaro/>...
Reading symbols from /home/john/Downloads/Python-2.6.4/python...done.
(gdb) run
Starting program: /home/john/Downloads/Python-2.6.4/python /home/john/bin/dumpcore.py
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x0000000000468d67 in PyString_FromString (str=0xdeadbeef <Address 0xdeadbeef out of bounds>) at Objects/stringobject.c:116
116             size = strlen(str);
(gdb) py-bt
Undefined command: "py-bt".  Try "help".
(gdb) python
>import sys
>sys.path.insert(0, "/home/john/Downloads/Python-2.7/Tools/gdb")
>import libpython
>(gdb) py-bt
#10 Frame 0x8f0f90, for file /home/john/Downloads/Python-2.6.4/Lib/ctypes/__init__.py, line 496, in string_at (ptr=3735928559, size=-1)
    return _string_at(ptr, size)
#14 Frame 0x8ebf90, for file /home/john/bin/dumpcore.py, line 5, in bar (self=<Foo(someattr=42, someotherattr={'three': [(), (None,), (None, None)], 'two': 2L, 'one': 1}) at remote 0x7ffff6e03240>, string_at=<function at remote 0x7ffff6e1c990>)
        string_at(0xDEADBEEF) # this code will cause Python to segfault
#17 Frame 0x8ebd80, for file /home/john/bin/dumpcore.py, line 12, in main (f=<Foo(someattr=42, someotherattr={'three': [(), (None,), (None, None)], 'two': 2L, 'one': 1}) at remote 0x7ffff6e03240>)
    f.bar()
#20 Frame 0x8eb680, for file /home/john/bin/dumpcore.py, line 16, in <module> ()
    main()
(gdb) 

这篇关于使用 gdb 7 对调试 Python 程序的支持需要什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！