2

那里。我为 Python 3.1 编写了一些行为不端的代码。如果它是一些 C 代码，我会gdbserver先使用，附加到进程（它涉及一个相当复杂的命令行，python 进程在标准输入上接收其输入），启动我最喜欢的 GDB 前端，然后我会准备好弄清楚为什么会出错。

但它是蟒蛇。我刚刚尝试了该pdb模块，但是当它关​​闭时我无法中断该过程：我得到了一个“KeyboardInterrupt”（我需要更改命令链的其余部分以便他们试一试set_ptrace）

我尝试了 winpdb，它产生了奇怪的错误消息

   Unhandled Exception (in pyshared/rpdb2.py)

并在我附加到该过程之前要求输入“密码”。它给了我 winpdb 仅适用于 python2 的整体感觉。

我只是尝试gdb __main__.py附加到正在运行的进程，但可以想象到“格式无法识别”。

我错过的联机帮助页在哪里？

PS：哦，这是一个多线程进程，如果这很重要的话。

一个最小的例子：

import pdb

pdb.set_trace()  # press 'c' here to continue
while(True):
    print("hi")  # hit CTRL+C here ... will just kill the program with python 3.1

print("ooh")
4

4 回答 4

3

使用 pdb 的典型方法是使用以下命令：

import pdb;pdb.set_trace()

你想休息的地方。如果您希望中断是有条件的，那么您只需添加条件，例如：

if x > 1000:
    import pdb;pdb.set_trace()

不涉及 CTRL-C。

但是，如果您让 pdb 模块运行脚本，则会安装一个 CTRL-C 挂钩：

python3 /path/to/stdlib/pdb.py myscript.py

一种更短更简单的写法是：

python3 -m pdb myscript.py

一些 linux 发行版还会在 /usr/bin 中创建指向 pdb.py 的链接，这意味着您可以将其作为命令获取：

pdb3 myscript.py

上面所有这三个命令都做同样的事情。然而，那个东西与 不同pdb.set_trace()，因为按下 CTRL-C 将进入事后调试。这意味着您无法单步执行代码，因为下一步将退出程序。因此，它远不如上述技术有用。然而，它可以是一种快速的方法来找出你的代码中的哪些内容花费了很多时间，当它运行缓慢时，它会允许你在正确的位置放置一个 set_trace() 来找出它为什么会这样减缓。

正如您在上面指出的那样，它确实在 Python 3.1 中似乎被破坏了。然而，它确实适用于 Python 3.2。

它只适用于简单的情况，但在更复杂的情况下，您需要使用分析来找到罪魁祸首。

于 2012-08-11T07:13:01.667 回答
1

我正在使用pdb这个，这对我来说很好。按下 Ctrl-C 后，您可以事后调试程序的状态，并且您将可以访问回溯中的所有堆栈帧。如果要进行实时调试，请在 Ctrl-C 发生的位置设置断点并重新开始。

于 2012-08-10T10:25:46.360 回答
0

因此，到目前为止，我最好的做法是使用 pdb（确实），但set_trace()仅在发生 KeyboardInterrupt 时才调用。这似乎是 python 3.1 中唯一的工作方式

于 2012-08-10T13:32:49.207 回答
0

一种结合按需中断和python解释器调试的方法可能是使用另一个信号，例如SIGUSR1，让它改变一个全局“调试”标志，并set_trace()在调试==真时有条件地调用。

于 2012-08-24T08:59:47.567 回答