在我点击n来评估一条线之后,我想回去然后点击s以进入该功能,如果它失败了.这可能吗?
文档说:
j(ump)lineno 设置将要执行的下一行.仅适用于最底部的框架.这使您可以跳回并再次执行代码,或者跳转到跳过您不想运行的代码.
Abr*_*ham 36
GNU调试器,gdb:它非常慢,因为它一次撤消单个机器指令.
Python调试器,pdb:该jump
命令会在代码中向后转,但不会反转程序的状态.
对于Python,扩展的python调试器原型epdb是出于这个原因而创建的.这是论文,这是程序和代码.
我使用epdb作为起点来创建一个实时反向调试器作为我的硕士学位的一部分.论文可在线获取:将反向调试和实时编程结合起来,实现计算机编程中的视觉思维.在第1章和第2章中,我还介绍了大多数反向调试的历史方法.
Mik*_*maa 10
反向调试(返回先前记录的应用程序状态或向后单步调试)通常是汇编或C级调试器功能.例如gdb可以做到:
https://sourceware.org/gdb/wiki/ReverseDebug
反向调试非常复杂,可能会有50.000x的性能损失.它还需要调试工具的广泛支持.Python虚拟机不提供反向调试支持.
如果您正在交互式评估Python代码,我建议尝试提供基于HTML的交互式Python shell的IPython Notebook.您可以轻松编写代码并混合和匹配订单.但是,没有pdb调试支持.有IPDB这对于进入调试命令提供了更好的历史和搜索功能,但它不能直接做向后跳跃无论是作为据我所知.
Sim*_*nJM 10
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博客上,安装和使用说明在RevDB bitbucket页面上.