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,

Diogo

28 comments
Comment actions Permalink

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.

0
Comment actions Permalink

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.

0
Comment actions Permalink

Hi Diogo,

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

Is it a local or remote interpreter?

0
Comment actions Permalink

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.

1
Comment actions Permalink

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.

0
Comment actions Permalink

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.

0
Comment actions Permalink

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.

0
Comment actions Permalink

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.

0
Comment actions Permalink

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

1
Comment actions Permalink

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.

1
Comment actions Permalink

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?

 

2
Comment actions Permalink

I'm having the same issue

0
Comment actions Permalink

Same issue.

PyCharm 2020.1.2

Python 3.7.6

MacOS 10.15.5

0
Comment actions Permalink

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.

0
Comment actions Permalink

I'm having the same issue

0
Comment actions Permalink

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? 

0
Comment actions Permalink

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

0
Comment actions Permalink

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. 

0
Comment actions Permalink

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.

2
Comment actions Permalink

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. 

0
Comment actions Permalink

I am having this same problem. It doesn't seem to be related to the above-linked issue.

0
Comment actions Permalink

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.

0
Comment actions Permalink

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

0
Comment actions Permalink

The issue with cython speedups is known https://youtrack.jetbrains.com/issue/PY-42679
See the issue description for a workaround.

0
Comment actions Permalink

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.

 

0
Comment actions Permalink

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.

0
Comment actions Permalink

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.

0
Comment actions Permalink

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.

0

Please sign in to leave a comment.