PyCharm 2020.1 not stopping on breakpoints anymore.

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.

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.

Hi Diogo,

I'm wondering if it's code-specific or reproducible even with something basic?

Is it a local or remote interpreter?

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.

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.

Found it!!! Yay!!! The problem starts as soon as I enable pytest-cov with the project. To reproduce:

• Take this example project: https://github.com/diogobaeder/pycharm_debug_django - clone it
• Disable Django support in the IDE
• Set the test runner to "pytest"
• Create a runner template with pytest - optional, but I did this -, set the project root as PYTHONPATH
• Put some breakpoints in the only test available at the "foo" module
• Try to debug the test case - it won't stop at the breakpoints
• Now, comment out lines 6 and 7 in "pytest.ini" (the ones that define the module to cover)
• Try again to debug the test case - now it will stop as expected

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.

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

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.

Hi guys, 

@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'm having the same issue

Same issue.

PyCharm 2020.1.2

Python 3.7.6

MacOS 10.15.5

Same issue with me - also on MacOS 10.15.5 with PyCharm 2020.1.2. Sometimes breakpoints work, but not always. My guess is that there is a mismatch between the debugger's line number and the line number of the breakpoint i.e. if you attempt to put a breakpoint on line 10, it is actually being placed a few lines before or after for some reason.

I'm having the same issue

Hi, 

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? 

Hi Antonina,

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.

Cheers,

Diogo

Hi Diogo, 

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. 

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
t.start()
File "/Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.7/lib/python3.7/threading.py", line 852, in start
self._started.wait()
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
waiter.acquire()
KeyboardInterrupt

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.

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 linked issue is different from the problem that I am facing, unfortunately.

I tried to distill my code down to the bare minimum to demonstrate the issue and put it into this Github Gist: https://gist.github.com/apacha/df9c5db38261ba82fc40de6fcf678c5b#file-breakpoint-debug-train-py-L68 

It requires a few libraries, but you should be able to install them easily. https://gist.github.com/apacha/c3c4fbde61fa0e7bbd17894d02484f1e is probably excessive for debugging this, but it lists all the libraries that I have in my virtual environment.

Try to set a breakpoint in line 68 and the play with the num_workers variable. When setting it to 0, everything works fine, but as soon as you go to 1 or above, the breakpoint behavior gets really weird. It stops at first but continuing does not work anymore. Looks like a deadlock to me. 

Similarly, a breakpoint in line 28 only stops once per iteration, even though there are multiple print statements happening on different workers. When letting the program run for a little while and then add the breakpoint to line 28, you can reproduce a similar problem, where the program stops at first, but upon resuming execution it enters a deadlock behavior and freezes.

Keep in mind that you might not experience the issue immediately, but need to let the program run for a few seconds before you set the breakpoint.

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?

Best.

Updates:
* 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

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.

I had this problem. I solved it (for me). Lots of the previously mentioned corrections were mentioned by colleagues and attempted, none worked.

In my particular case there were a few problems.
1 authentication, had to reset docker root password to get my pycharm actually connected to remote session.
2 I had a crash happening at some jumbled try code in pydevd_constants.py in and around a gevent import statement, line 139 in my case. I fixed that bit of code up, but what it lead me to was the realization that gevent was not getting imported.
3 So I got on my docker and ran "yum install python-gevent" (this resolved my experience of the symptoms detailed in this thread, or similar). Obviously the install line would be different for your environments perhaps. Good luck.

Hi,

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:
PYDEVD_USE_CYTHON=NO;
PYDEVD_USE_FRAME_EVAL=NO

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 version:

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
Memory: 734M
Cores: 8
Registry: debugger.watches.in.variables=false
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.

This was happening to me too; I'm on macOS Mojave and not Catalina yet. I was able to solve it like so:

First off, make sure you have disabled pytest coverage package -- pytest-cov -- I just flatout uninstalled it so as not to interfere -- I run code coverage in a docker container instead with a separate requirements.txt file.

Next, I installed Python 3.7 from homebrew instead of using the macOS built-in Python, which for me was 3.8. `brew install "python@3.7"`. This installed Python 3.7 to /usr/local/Cellar/python/3.7.7/bin

Then in PyCharm, I added a new Interpreter option: Virtualenv and made the base interpreter the Cellar path to python3: /usr/local/Cellar/python/3.7.7/bin/python3

Then in my pytest run configurations I made sure the default interpreter was the project interpreter -- the Virtualenv one, which should be PROJECT/venv.

After this all my debugging worked, both raw scripts and pytest tests.

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.