使用 GDB 调试 Python 内存 [英] Python memory debugging with GDB

问题描述

我们有一个使用 OpenSSL 的 Python 绑定的 Linux 应用程序，我怀疑它会导致随机崩溃.有时，我们会看到它崩溃并显示以下消息:

We have a Linux application that makes use of OpenSSL's Python bindings and I suspect it is causing random crashes. Occasionally, we see it crash with the message:

Python 致命错误:GC 对象已被跟踪

Python Fatal Error: GC Object already tracked

这可能是库方面的编程错误，或者是内存损坏的症状.给定一个核心文件，有没有办法知道它执行的最后一行 Python 源代码?或者如果它附加在GDB中?我意识到它可能都是编译好的字节码，但我希望有人可能已经处理过这个问题.目前它正在运行，跟踪模块处于活动状态，我们希望它会再次发生，但可能需要很长时间.

which would appear to be either a programming error on the part of the library, or a symptom of memory corruption. Is there any way to know the last line of Python source code it executed, given a core file? Or if it is attached in GDB? I realize it is probably all compiled bytecode, but I'm hoping there someone out there may have dealt with this. Currently it is running with the trace module active and we're hoping it will happen again, but it could be a long while.

推荐答案

是的，你可以这样做:

(gdb) print PyRun_SimpleString("import traceback; traceback.print_stack()")
  File "<string>", line 1, in <module>
  File "/var/tmp/foo.py", line 2, in <module>
    i**2
  File "<string>", line 1, in <module>
$1 = 0

也应该可以使用 python gdbinit 文件，但它对我不起作用.如果您想查看它，请在此处讨论.

It should also be possible to use the pystack command defined in the python gdbinit file, but it's not working for me. It's discussed here if you want to look into it.

另外，如果您怀疑内存问题，值得注意的是您可以使用 valgrind使用 python，如果你准备重新编译它.此处描述了该过程.

Also, if you suspect memory issues, it's worth noting that you can use valgrind with python, if you're prepared to recompile it. The procedure is described here.

这篇关于使用 GDB 调试 Python 内存的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！