PyCharm 2020.1 not stopping on breakpoints anymore.

Hi guys,

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?

Thank you,



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:

  • Take this example project: - 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.


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).


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?



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.


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/", line 1769, in do_it
File "/Applications/", line 852, in start
File "/Applications/", line 552, in wait
signaled = self._cond.wait(timeout)
File "/Applications/", 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.


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.


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


I'm having the same issue


Same issue.

PyCharm 2020.1.2

Python 3.7.6

MacOS 10.15.5


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:

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 (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 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
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.


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.


Here: Ubuntu 20.04, PyCharm 2021.2.1, Python 3.9

Solved for me.

Here's what I just experienced:

  1. Breakpoints that I add in the IDE don't work.
  2. Adding a code line 'breakpoint()' works AND makes all the other breakpoints work.
  3. Removing that 'breakpoint()' line.
  4. After that I can still set and unset breakpoints in the IDE and they keep working as expected.

I solved the not stopping at breakpoints on my machine with:

find . -name '*.pyc' -delete

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.

Best regards,





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.


Hi Diogo,

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 , 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 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


Please let me know if you need additional info. 


Hello Alexander Pacha! 


There is an existing issue 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
See the issue description for a workaround.


Please sign in to leave a comment.