是否有可能在pdb中倒退？

Question

在我点击n来评估一条线后，我想返回然后点击s以进入该功能，如果它失败了。这可能吗？

文档说：

j（ump）lineno 设置将要执行的下一行。仅适用于最底部的框架。这使您可以跳回并再次执行代码，或者跳转到跳过您不想运行的代码。

Answer 1

GNU调试器，gdb：它非常慢，因为它一次撤消单个机器指令。

Python调试器，pdb：jump命令会在代码中向后引导，但不会反转程序的状态。

对于Python，由于这个原因，创建了扩展的python调试器原型epdb。这是thesis，这里是program and the code。

我使用epdb作为创建实时反向调试器的起点，作为我的硕士学位的一部分。论文可在线获取：Combining reverse debugging and live programming towards visual thinking in computer programming。在第1章和第2章中，我还介绍了大多数反向调试的历史方法。

Answer 2

反向调试（返回先前记录的应用程序状态或向后单步调试）通常是汇编或C级调试器功能。例如。 gdb可以做到：

https://sourceware.org/gdb/wiki/ReverseDebug

Bidirectional (or reverse) debugging

Reverse debugging is utterly complex, and may have performance penalty of 50.000x。它还需要调试工具的广泛支持。 Python虚拟机不提供反向调试支持。

如果您是交互式评估Python代码，我建议尝试IPython Notebook，它提供基于HTML的交互式Python shell。您可以轻松编写代码并混合和匹配订单。但是，没有pdb调试支持。 ipdb为输入的调试命令提供了更好的历史记录和搜索功能，但据我所知，它不会直接向后跳转。

Answer 3

PyPy已经开始实现RevDB，它支持反向调试。

它（截至2017年2月）仍处于alpha阶段，仅支持Python 2.7，仅适用于Linux或OS X，并要求您自己从特殊版本构建Python。它也很慢并且使用了大量的RAM。引用Bitbucket页面：

  

请注意，日志文件通常以每秒1-2 MB的速度增长。假设尺寸不是问题，限制因素是：

     

  
• 重播时间。如果您的录制执行时间超过几分钟，则重播将非常缓慢。有时需要在一个会话中多次遍历整个日志。如果错误是随机发生但很少发生，你应该运行录音几分钟，然后重复该过程并重复尝试，直到你遇到崩溃。
  
• 重放的RAM使用情况。对于重放，RAM要求比录制要大10或15倍。如果这太多了，你可以在_revdb / process.py中尝试使用较低的MAX_SUBPROCESSES值，但它总是要大几倍。
  

详细信息位于PyPy blog，安装和使用说明位于RevDB bitbucket page。