PyCharm 2020.1 not stopping on breakpoints anymore. Follow
PyCharm Professional 2020.1 is not stopping on breakpoints for me anymore, when I test my project with pytest and run tests in debug mode. I already wiped out my .idea/ directory to start all over, already tried checking and unchecking "gevent support", and none of these options make the debugger honor the breakpoints.
Can somebody help me?
Guys, this is super frustrating. It's been many versions already with the IDE having troubles with non-stopping breakpoints, and this is a very important part of the process for a number of developers, including myself. For me, it's actually the most important feature, because I debug code a LOT, both when running and testing, and having the debugger stopping to work as expected makes the experience a nightmare for me.
Can you please address more effort into fixing this recurring issue?
Please sign in to leave a comment.
Hello everyone, I got to this post because I had the same problem with debug not stopping at breakpoints...
The debug only stopped at the breakpoints of the main script, but did not stop at any other script in the project.
To my surprise, I had configured the Run/Debug Configurations dialog wrong.
In this dialog window, on the Configurations tab, the first field is labeled as Script path by default, but this label is actually a combobox, the other option is Module name, and after I choose it and define the name of the main script, the debug worked on all the scripts of the project and not just for the main script.
I hope this can help other people who came here through a simple google search.
Found it!!! Yay!!! The problem starts as soon as I enable pytest-cov with the project. To reproduce:
Would this be enough info for the dev team to find out the issue? Reiterating, this started happening on PyCharm 2020.1, so it must be some change introduced in this version.
Folks, this is getting ridiculous, I'm getting many comments from people having the same issue, and it hasn't been fixed for several versions already. Why isn't this being prioritized? Debugging is one of the most important features in the IDE, it should be working fine. I don't care if a color of a word is incorrect, or if it fails to do some refactoring it was supposed to, but I care a lot about debugging with the IDE, instead of having to textually define breaking points within ipdb.
And it's even more irritating for paying users, like myself (and probably others).
@Devlocalca i have a similar problem.
I switched Pycharm 2019 to Pycharm 2020.1 (today).
I removed all Python installations, installed Python 3.7.7 from scratch
I created a new virtual environment and the breakpoint just doesn't stop.
The breakpoint seems to have stopped working.
Has anyone managed to solve?
I have the same problem which started with PyCharm 2019.3 installed fresh on a new MacBook Pro with Catalina. Had hopes 2020.1 might fix it. It isn't stopping on break points for several different code sets (i.e. unrelated projects). I have a second Mac running High Sierra which has had no such problems.
Deleting the .idea folder or cache made no difference.
this just started happening to me, will not stop at breakpoints (PyCharm 2020.1 - June 4th, 2020)
I have changed no settings, it just stopped working.
I'm not running tests, I don't know what 'pytest' is or how to set it as a test runner as described above. I don't know how to enable pytest-cov with any project.
I have 'invalidated caches' and restarted.
I have rebooted my machine, nothing works.
Any help would be appreciated, I have some code that I really need to break on right now to debug, under a deadline here.
I am using PyCharm Professional 2020.1.2
I have been using Python 3.8.2, breakpoints were working earlier today. I think I saw a popup that PyCharm was updated on my machine (from toolbox), so something may have changed.
Same problem here with PyCharm 2020.1.2 on macOS Catalina 10.15.5 with Python 3.7 (Anaconda installation). Some breakpoints are being respected, others aren't. I can't find any clear pattern why breakpoints are disregarded, but I know that I have massive problems developing, when my breakpoints don't break. Even the same breakpoint is sometimes ignored.
My best guess is that it is related to multi-threading. Breakpoints from the main thread are usually respected, but coming from a background worker they often aren't. I also get a deadlock-like situation sometimes with breakpoints, with this stacktrace when I terminate the program:
Traceback (most recent call last):
File "/Applications/PyCharm.app/Contents/plugins/python/helpers/pydev/_pydevd_bundle/pydevd_comm.py", line 1769, in do_it
File "/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.7/lib/python3.7/threading.py", line 852, in start
File "/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.7/lib/python3.7/threading.py", line 552, in wait
signaled = self._cond.wait(timeout)
File "/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.7/lib/python3.7/threading.py", line 296, in wait
libc++abi.dylib: terminating with uncaught exception of type std::__1::system_error: Broken pipe
I guess, I will downgrade to an old PyCharm version until this issue is resolved.
Sorry, another small update: I just tried putting a breakpoint() function call (I'm using Python 3.8), and this works as expected. So PyCharm is just not stopping at breakpoints that I put on the left pane (as red balls), but it does stop on the breakpoint function call.
Oh, I see, thank you for letting me know.
Although it is strange that it's not reproducible in older versions because the bug is known and it's not since 2020.1 https://youtrack.jetbrains.com/issue/PY-20186
I'm having the same issue
If you read through the comments before yours, you'll notice that I already created a project just for reproducing that issue, with notes on how exactly to reproduce it. Here's the comment: https://intellij-support.jetbrains.com/hc/en-us/community/posts/360008107400-PyCharm-2020-1-not-stopping-on-breakpoints-anymore-?page=1#community_comment_360001593039
If you need more information than that, or some different approach, please let me know, so that I can further help you.
Since sometime yesterday, I also have a similar issue using Pycharm Pro 2020.1.1. Namely, the debugger doesn't stop at breakpoints outside the scope of my test functions.
So what changed? All I remember is that I clicked a PyCharm popup button to install cython speedups https://www.jetbrains.com/help/pycharm/cython-speedups.html (I'm using Python 3.7.7 on Pop_OS! 20.04). Unfortunately, I cannot find any way or documentation on how to reverse my decision.
I can confirm that switching to a new project (and new conda environment), the debugging breakpoints work again before I click on the install cython speeds popup.
Can somebody please share how to uninstall cython speedups?
* I was not able to reproduce the problem by install cython speedups in another PyCharm project (Python 3.8, independent env from above).
* uninstall pytest-cov as mentioned somewhere above changed nothing
* using "breakpoint()" is a temporary workaround but not ideal
I had the same problem with running Apache Beam with Cython under windows (but AB is different story).
Workaround working for me for the breakpoints problem:
Run with these ENV variables:
Works for me under venv interpretter. Did not get it to work with conda environments, but to be honest I have not tried it, when I got this working.
Tested on Python 3.7.7 under Win10
PyCharm 2020.1.3 (Professional Edition)
Build #PY-201.8538.36, built on July 7, 2020
Licensed to Jakub Vedral
Subscription is active until July 25, 2020
Runtime version: 11.0.7+10-b765.64 amd64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o.
Windows 10 10.0
GC: ParNew, ConcurrentMarkSweep
Non-Bundled Plugins: com.github.b3er.idea.plugins.arc.browser, ru.meanmail.plugin.requirements
More "extreme" way was to remove Cython package from venv, but I don't know if it is related to breakpoints aswell and not only to Apache Beam.
Hope this helps someone.
Had a similar issue in Pycharm 2020.3, Pycharm not stopping on any breakpoints in flask callbacks. Unchecking "Gevent compatilble" in Pycharm settings (under Python Debugger) solved the issue. Hope this helps.
Same Issue, Pycharm 2020.2 breaking points not stopping at all for Django project files.
I have come across this issue today. Installed a fresh version of Pycharm professional on my new machine. Out of no where Pycharm started ignoring the breakpoints.
I solved the not stopping at breakpoints on my machine with:
in the project root directory.
Unfortunately the problem is getting worse with every new version. With 2022.1 the behavior of the program execution can change with each breakpoint. It depends if I set a breakpoint outside an "if" clause or inside. Settings a breakpoint at the "wrong" line can lead to a crash of the Python program. So what I observed:
- Some breakpoints are ignores
- Some breakpoints lead to a crash
- Some breakpoints change the program execution!!! Which means that some variables do not have the expected contents.
Debugging with PyCharm is nowadays a big mess.
I urgently expect that Jetbrains fixes theses issues instead adding new features which are just for a few users useful. Debugging is THE key feature of a good IDE.
Small update: I tried again to delete the .idea/ directory, plus the __pycache__/ directory (as per someone else's comment in another ticket), and the breakpoints are still not being respected.
I'm wondering if it's code-specific or reproducible even with something basic?
Is it a local or remote interpreter?
I tested 4 different projects: 2 of them run on Django, 2 of them on Flask. Only one of the Flask-based projects is able to stop at breakpoints. Both Flask-based projects run on Python 3.6, and both Django-based ones run on Python 3.8.
I tried diffing the .idea/ folders from all projects, but couldn't find any relevant difference that made me thing it might be causing the issue. So this is leading me to think that the problem might be not with configurations, but with something in the structure of those projects that might cause the debugger to not stop at breakpoints.
[EDIT] I'm using a local interpreter, no remote debugging going on.
Sergey, if you want to setup a simple project for me to test and try to see if it runs, I can do that, if it helps.
For the sake of the experiment, could you create a new project (Flask or Django) and let me know if the problem reproduces?
Does it happen only in tests?
If it works in a new project, switch its Project Interpreter to one of those you use in the projects where the issue is reproducible and see how it goes.
If you experience the issue mentioned above https://youtrack.jetbrains.com/issue/PY-20186 , please vote for the ticket in order to increase its priority.
If not, please provide more details about the project, try creating a new test project, and reproduce the issue.
>if you attempt to put a breakpoint on line 10, it is actually being placed a few lines before or after for some reason
Could you please share a simplified code example and steps to reproduce?
I apologize for being not accurate. My reply was to Mario Dagenais and Pooyae .
Regarding the issue you have described there was an answer from my colleague https://intellij-support.jetbrains.com/hc/en-us/community/posts/360008107400/comments/360001595839
Please let me know if you need additional info.
Hello Alexander Pacha!
There is an existing issue https://youtrack.jetbrains.com/issue/PY-41258 please take a look, feel free to vote if this is your case as well, If not, please provide me with a simplified code example and steps to reproduce.
Thank you in advance.
I am having this same problem. It doesn't seem to be related to the above-linked issue.
The issue with cython speedups is known https://youtrack.jetbrains.com/issue/PY-42679
See the issue description for a workaround.
I've had the same issue for a few latest versions now. Mine gets fixed when I provide a "Add Content Root" in Settings > Project Structure. I'm not sure if the problem surfaces because I use soft links for some of the directories in the project path. It also manifests when I click an error on the log and end up with a readonly file.