PDB不会在断点处停止
我对直接使用 pdb 进行调试还很陌生,并且在调试 Django 应用程序时遇到了一些问题。这就是我正在做的:
python -m pdb manage.py runserver
(pdb) b core/views.py:22
Breakpoint 2 at /Users/raphaelcruzeiro/Documents/Projects/pdb_test/core/views.py:22
(Pdb) c
但是执行直接通过断点。我错过了一些命令吗?该手册没有详细说明如何设置断点。
I'm quite new with debugging directly with pdb and I am having some issues debugging my Django application. Here is what I'm doing:
python -m pdb manage.py runserver
(pdb) b core/views.py:22
Breakpoint 2 at /Users/raphaelcruzeiro/Documents/Projects/pdb_test/core/views.py:22
(Pdb) c
However the execution passes directly through the breakpoint. Am I missing some command? The manual doesn't elaborate on setting a breakpoint anymore than this.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(8)
我也遇到过同样的问题。
尝试类似 python -m pdb ./manage.py runserver --nothreading --noreload 127.0.0.1:8080 。它为我解决了这个问题。
看来 PDB 的断点是特定于线程的,并且
--nothreading
和--noreload
选项对于避免可能混淆 PDB 的某些分叉是必要的。这也是set_trace
起作用的原因,因为它是在感兴趣的线程内直接调用的。I've been through the same problem.
Try something like
python -m pdb ./manage.py runserver --nothreading --noreload 127.0.0.1:8080
. It solved the issue for me.It seems that breakpoints with PDB are thread-specific, and the
--nothreading
and--noreload
options are necessary to avoid some forking that may confuse PDB. This is also whyset_trace
works, as it's called directly inside the thread of interest.我通常更喜欢在源代码本身中使用
set_trace()
,这样开发服务器将在添加/删除时重新加载,并且我不需要停止并再次启动它。例如:当访问视图时,pdb将启动。
I usually prefer
set_trace()
in the source itself, that way the dev server will reload when added/removed, and I don't need to stop and start it again. For example:When the view is accessed, pdb will kick in.
当我过去看到这个问题时,通常是因为有人在实际上未连接到正在运行的 Python 语句的行上设置了断点。例如,空行、注释行、多行语句的错误部分。
When I've seen this problem in the past, it's usually because someone has set the breakpoint on a line that is not actually connected to a Python statement that is run. For example, blank lines, comment lines, the wrong part of a multi-line statement.
我注意到的一件奇怪的事情是,当您反复按 Enter 时,PDB 提示符会重复您之前的操作。此外,如果您在程序运行时按 Enter 键,PDB 会缓冲输入并在提示出现后应用它。就我而言,我正在使用 PDB c(ontinue) 运行一个程序。我的程序在初始化期间将大量调试信息写入标准输出,因此我按了几次 Enter 键,将已写入的输出与触发断点后将要写入的输出分开。然后,当我通过某些外部操作触发断点时,PDB 将在断点处停止,但随后应用“缓冲输入”,重复 c(ontinue) 操作。一旦我停止按回车键,一切就开始正常工作。
这听起来可能有点奇怪,我没有太多研究这个问题,但它为我解决了问题。也许它对其他人有帮助。
One strange thing I have noticed is that the PDB prompt repeats your previous action when you repeatedly hit enter. Moreover, if you hit enter whilst your program is running, PDB buffers the input and applies it once the prompt appears. In my case, I was running a program using PDB c(ontinue). My program was writing lots of debug info to stdout during initialization, so I hit enter a couple of times to separate the already written output from the output that was going to be written once the breakpoint was triggered. Then, when I triggered the breakpoint via some external action, PDB would stop at the breakpoint but then apply a 'buffered enter' which repeated the c(ontinue) action. Once I stopped hitting enter it all started working normally.
This may sound a bit strange, and I haven't investigated this issue much, but it solved the problem for me. Maybe it helps someone else.
我使用
pyproject.toml
配置进行了项目设置,删除[tool.pytest.ini_options]
部分中pytest
的覆盖率相关设置修复了pdb 问题未按预期工作。从
pyproject.toml
中的[tool.pytest.ini_options]
部分删除或注释掉--cov-*
覆盖率相关选项适用于我。I had my project setup with
pyproject.toml
config, Removing coverage-related settings forpytest
in[tool.pytest.ini_options]
section fixed the issue of pdb not working as expected.Removing or commenting out the
--cov-*
coverage-related options from[tool.pytest.ini_options]
sections inpyproject.toml
worked for me.我在 PyTorch 中编写神经网络时遇到了这个问题。与已接受的答案类似,问题是我的 DataLoader 分离了多个线程。删除 num_workers 参数允许我在单个线程上进行调试。
如果您遇到此问题,一个简单的解决方法是跟踪代码中使用多处理的位置,并将其调整为运行单个线程。
I ran into this issue when writing a neural network in PyTorch. Similar to the accepted answer, the problem was that my DataLoader spun off multiple threads. Removing the
num_workers
argument allowed me to debug on a single thread.If you are running into this issue, a simple fix would be to track down where in your code you are using multiprocessing, and adjust it to run a single thread.
我只是花了太长时间才弄清楚这一点,我想我会分享它以减轻某人的痛苦。
无论我做什么,它都不会在
b [fullfilepath]:[Line number]
处中断。我尝试执行
b [class].[function]
但这也不起作用。最终我在所有类之外的 python 函数上放置了一个断点,然后我就命中了它。
然后我这样做了:
然后我到达了断点。换句话说,在设置断点之前需要先导入该类,否则会给出错误,指出未找到该类。
然后我想起几乎所有的 python 代码都在某种形式的虚拟环境中运行,并且我为周围的相同 python 代码设置了断点,但不是在 pip 虚拟环境中运行的 python 代码实际上是由python执行的。因此它没有停止并没有断点。
因此,如果您使用完整路径,请确保它是从虚拟环境内部到实际通过 python 执行的 python 脚本而不是另一个文件所看到的完整路径。 它只会在实际解析的完全相同的 python 文件上中断。
换句话说,如果您有:
但您正在执行
python3.10 -m pdb /opt/MyEnv/test.py< /code>,那么它不会在第 100 行中断,使用:
即使它是完全相同的代码。对于具有 C/C++ 背景的我来说,这让我很困惑。然而,它会在以下方面很好地打破:
另外,为了阻止自己发疯,首先打破全局范围内的某些内容,然后导入类,然后打破这些类中的成员函数。
I just spent way too long figuring this out, and i thought i'd share it save someone the pain.
It wouldn't break at
b [fullfilepath]:[Line number]
no matter what i did.I tried doing
b [class].[function]
and that didn't work either.Eventually i put a breakpoint on a python function outside of all the classes and i hit it.
I then did:
And I hit the breakpoint. In other words the class needs to be imported first before setting the breakpoint else it'll give an error saying it's not found.
Then i remembered that nearly all python code runs in some form of virtual environment, and i had set the breakpoint for the same python code that was laying around but not the running python code in the pip virtual env that was actually being executed by python. For that reason it didn't stop and the breakpoint.
So make sure that if you use a full path, it's the full path as it's seen from inside the virtual environment to the python script that's actually being executed through python and not another file. It only breaks on the exact same python file it's actually parsing.
In other words if you have:
But you're executing
python3.10 -m pdb /opt/MyEnv/test.py
, then it wont break on line 100 using:Even though it's the exact same code. This was confusing to me coming from a C/C++ background. It will however break fine on:
Also to stop yourself going crazy, start by breaking on something in global scope then import classes and then break on member functions in those classes.
我在创建必须始终是多线程的 Tkinter 程序时遇到了这个问题,因此我无法分离出线程代码来测试。对我有用的方法是在我实际想要中断的位置之前手动将
breakpoint()
插入到我的代码中。然后,当出现此断点的(Pdb)
提示时,使用break linenumber
在所需位置创建一个新断点,然后继续
。我认为这是可行的,因为创建它的同一线程将始终是击中它的线程。示例:
I was having this issue when creating a Tkinter program that must always be multithreaded, so I could not separate out my threaded code to test. What worked for me is to manually insert
breakpoint()
into my code before the location I actually want to break. Then, when in the(Pdb)
prompt for this breakpoint, create a new breakpoint at the desired location withbreak linenumber
, andcontinue
. I assume this works because the same thread that is creating it will always be the one that hits it.Example: