pdb | 易学教程

What is the simplest way of using Python pdb to inspect the cause of an unhandled exception?

阅读更多关于 What is the simplest way of using Python pdb to inspect the cause of an unhandled exception?

问题 I just converted all my unit test data from JSON to YAML, and now an exception is raised somewhere in my code. More specifically, this is printed traceback: Traceback (most recent call last): File "tests/test_addrtools.py", line 95, in test_validate_correctable_addresses self.assertTrue(self.validator(addr), msg) File "/Users/tomas/Dropbox/Broadnet/broadpy/lib/broadpy/addrtools.py", line 608, in __call__ self.validate(addr) File "/Users/tomas/Dropbox/Broadnet/broadpy/lib/broadpy/addrtools.py"

python pdb lambda function global name error

阅读更多关于 python pdb lambda function global name error

问题 I was testing a fix using pdb.set_trace() to make sure it worked the way I expected before implementing it and kept getting a weird error. (Pdb) test = [1,2,3,4,4,3,2,1] (Pdb) max(range(len(test)),key=lambda i: test[i]) *** NameError: global name 'test' is not defined So I moved to my localmachine to make sure I could reproduce as simply as possible before asking for help. In ipython I get the exact same behavior. In [1]: test = [1,2,3,4,4,3,2,1] In [2]: max(range(len(test)),key=lambda i:

ipython debugger: full traceback on interactive pdb?

阅读更多关于 ipython debugger: full traceback on interactive pdb?

问题 I recently switched from ipython0.10 to ipython0.11. In ipython0.11, I only see a small snippet of the full traceback when the python debugger engages (i.e. using %pdb ), whereas in ipython0.10 I'd see the full traceback. As far as I can tell, the full traceback is not directly accessible from the pdb command line - you can navigate through it with 'u' but can't see it directly. So, is there any way to show the full traceback? Such as a configuration parameter? Or, even more usefully, is

How to step through Python expression evaluation process?

阅读更多关于 How to step through Python expression evaluation process?

问题 I want to build a visual debugger, which helps programming students to see how expression evaluation takes place (how subexpressions get evaluated and "replaced" by their values, something like expression evaluation visualizer in Excel). Looks like you can't step through this process with Python's pdb, as its finest step granularity is line of code. Is it somehow possible to step through Python bytecode? Any other ideas how to achieve this goal? EDIT: I need a lightweight solution that can be

Running wxPython 2.9 on OS X 10.8 (64 bit)

阅读更多关于 Running wxPython 2.9 on OS X 10.8 (64 bit)

I have EPD 7.3 and have installed wxPython 2.9 through the Enthought repositories. I tried running winPDB, which requires wxPython and I got this message : This program needs access to the screen. Please run with a Framework build of python, and only when you are logged in on the main display of your Mac. I have seen similar messages from wxPython on Mac, but I haven't found a solution yet. Does anyone know about this message? And, has anyone got WinPDB to work on OS X 10.8 w/ wxPython 2.9? This error message will happen when the Python used to run a wxPython script is not a full framework

python中错误、调试、单元测试、文档测试

阅读更多关于 python中错误、调试、单元测试、文档测试

错误分为程序的错误和由用户错误的输入引起的错误，此外还有因为各种各样意外的情况导致的错误，比如在磁盘满的时候写入、从网络爬取东西的时候，网络断了。这类错误称为异常错误处理　　普通的错误处理机制就是在出错的时候返回一个错误代码，但是这样十分不方便，一是因为错误码是和正常结果一样的方式返回的，判断起来十分不方便，二是错误还需要一级一级的向上报，直到错误处理程序。所以高级语言通常都内置了一套 try...except...finally... 的错误处理机制，Python也不例外。 try: A#如果A中的代码执行过程中出错，就会执行B中的代码 except ZeroDivisionError as e: B finally: C#C中的代码无论是否出错都会正常执行（可以不要这个）<br>。。。如果错误有不同的类型，可以说使用多个except语句，每个语句处理一个类型的错误另外，可以在except后面加一个else，如果没有出错，会执行else Python 的错误其实也是一个类，所有的异常类型都是从BaseException类派生的 except在捕获错误时，不但捕获该类型的错误，而且还会把子类一网打尽 try: foo() except ValueError as e: print('ValueError') except UnicodeError as e: print

创建触发器启动pdb

阅读更多关于创建触发器启动pdb

1.登陆cdb sqlplus /nolog connect / as sysdba 2.创建启动某个pdb的触发器 create or replace trigger open_pdbs after startup on database begin execute immediate 'alter pluggable database ora12cpdb1 open'; end open_pdbs; 3.创建启动所有的pdb create or replace trigger open_all_pdbs after startup on database begin execute immediate 'alter pluggable database all open'; end open_all_pdbs; 来源： https://www.cnblogs.com/hxlasky/p/11974871.html

Debugging a python application that just sort of “hangs”

阅读更多关于 Debugging a python application that just sort of “hangs”

I have an event-driven application, written in python. After a while (usually >1 week) it appears to just stop responding to events. When this happens, I just ctrl-C and re-run and all is well-again. However, it's kind of annoying that this keeps happening and I have no idea what's causing it. Is there a way I can run my application that when this occurs and the application is no longer accepting connections, I can drop into a debugger and see what it's doing and why it's not taking connections? I've used pdb before, but the way I've used it ( if condition: pdb.set_trace() ) doesn't really

正确创建本地C++发布构建PDBS

阅读更多关于正确创建本地C++发布构建PDBS

在调试版本中遇到的一个问题是编译本地的C++应用程序。例如，许多局部变量消失了，因为代码生成器没有将它们放在堆栈上，而是将它们放在寄存器中，就像在调试生成中发生的那样。此外，release积极地构建对函数的内联调用，因此代码生成器将函数体直接放入调用方法中。一旦您习惯了编译器的模式，并了解了一点汇编语言，就不难理解在调试发行版生成代码时会发生什么。我想在本文中介绍的是在不加应用程序的情况下正确创建本地C++发布PDB所必需的精确开关，这样我就可以回答隐形的问题了。我将向您展示的开关与优化无关，PDB文件的创建不会影响优化。要设置的第一个开关是在编译器CL.EXE上，它是/Zi。此开关将调试信息放入.OBJ文件中，以便链接器将其放入最终PDB。您将在项目的C/C++属性页中设置这个开关。如下图接下来的三个开关应用于链接器LINK.EXE。第一个命令/DEBUG告诉链接器您要为该生成创建PDB文件。如下： /DEBUG开关有个小问题。打开它会告诉链接器您正在执行未优化的生成，所以/DEBUG隐式地打开/INCREMENTAL并实质上创建一个调试生成，尽管编译器优化会应用（但不是链接时代码生成优化）。这对您意味着链接器以“快速模式”链接，因此如果您的OBJ中有300个函数，但您只引用（即，使用）其中一个函数，那么链接器会将所有300个函数放入输出二进制文件中。是的

每个开发人员必须知道PDB文件知识

阅读更多关于每个开发人员必须知道PDB文件知识

大多数开发人员都意识到PDB文件有助于您进行调试，但仅此而已。如果你不知道PDB文件是怎么回事，不要觉得很糟糕，因为虽然有文档在那里，但它分散在周围，而且大部分是为编译器和调试器编写器准备的。虽然编写编译器和调试器非常酷和有趣，但这可能不是你的工作。我想做的是把每个在微软操作系统上进行开发的人都必须知道的PDB文件放在一个地方。这些信息也适用于本机开发人员和托管开发人员，不过我将提到一个特定于托管开发人员的技巧。我将从讨论PDB文件存储和内容开始。由于调试器使用PDB文件，我将详细讨论调试器如何为二进制文件找到正确的PDB文件。最后，我将讨论调试器在调试时如何查找源文件，并向您展示一个与调试器如何查找源代码相关的常用技巧。在我们开始之前，我需要定义两个重要的术语。在开发计算机上执行的生成是私有生成。在生成计算机上完成的生成是公共生成。这是一个重要的区别，因为调试在本地生成的二进制文件很容易，总是公共生成导致问题。所有开发人员需要知道的最重要的事情是：PDB文件和源代码一样重要！很多公司没有人能找到在生产服务器上运行的构建的PDB文件。如果没有匹配的PDB文件，您的调试挑战几乎是不可能的。通过大量的努力，可以在没有正确的PDB文件的情况下找到问题，但是如果您首先拥有正确的PDB文件，它将为您节省大量的资金。正如Visual Studio的开发经理约翰坎宁安（John

订阅 pdb