python - 使用 GDB 调试 Python 内存

Question

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

Python 致命错误：已跟踪 GC 对象

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

Answer 1

是的，你可以做这样的事情：

(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

也应该可以使用pystackpython gdbinit文件中定义的命令，但它对我不起作用。如果你想研究它，这里会讨论它。

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

Answer 2

如果你有 mac 或 sun box ，你可以使用dtrace和一个用 dtrace 编译的 python 版本来确定应用程序当时在做什么。注意：在 10.5 中，python 是使用 dtrace 预编译的，这非常好用。

如果这对您不可用，那么您可以导入 gc并启用调试，然后您可以将其输出到日志文件中。

要专门回答有关使用 GDB 调试的问题，您可能需要阅读python wiki 上的“使用 GDB 调试”。

Answer 3

如果您使用 CDLL 在 python 中包装 C 库，并且这是 64 位 linux，则很有可能您的 CDLL 包装器配置错误。CDLL 在所有平台上默认为 int 返回类型（在 64 位系统上应该是 long long），并且只希望您传入正确的参数。在这种情况下，您可能需要验证 CDLL 包装器...

Answer 4

除了以上所有之外，还可以通过trace 模块快速实现一个 adhoc 跟踪器。