PyCharm 2020.1 not stopping on breakpoints anymore.

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

find . -name '*.pyc' -delete

in the project root directory.  

I just had this issue. Similarly to other posters, debugging breakpoints in a local project submodule were not being triggered using a docker-compose based remote Python. 

The fix for me was to ensure that the 'path mapping' dialog in the run/debug config was correctly set. Using the default generated run/debug config does not seem to do this.

on Pycharm 2021.3.1 (Professional Edition), Build #PY-213.6461.77, built on December 28, 2021, Runtime version: 11.0.13+7-b1751.21 x86_64

I also have encountered the same issue and after digging through I've realized that in my case problem related to codecov. So, in that case, just provide flag --no-cov when you configure the test run (additional arguments field).

@Hongbo Miao I also had a capitalization difference in my path (on MacOS) and strangely that caused the breakpoints to not work.  Thanks for pointing that out.

Solution by Martin Bless worked for me.  Makes absolutely no sense.

I had the same problem but disabling pytest.ini solved the problem for me. Does anyone has the correct pytest.ini config so that tests debugging works? I am using the following params

[pytest]
testpaths =
    tests
norecursedirs=dist build .tox scripts
addopts =
    --cov-report term-missing --cov-branch  --cov-report xml --cov-report term --cov=src -vv --strict-markers -rfE

[run]
disable_warnings = no-data-collected

Breakpoints stopped working for us on all projects (Pycharm Professional 2021.3.2). To fix it, we went Run > Edit Configurations. Under Script path (first item), copy the value against this field. Then change Script path dropdown to Module Name. Choose any module and click Apply. Then reverse this step; so change back to Script path and paste the value back in and click Apply. For some reason, this was enough for the debugger to re-register the location of the script and breakpoints to start working again. It's a bit of a hack, but it worked for us.

Same issue with PyCharm 2022.1.3.

I noticed that breakpoints set inside the if __name__ == '__main__' block don't work, but breakpoints set outside do. When I set a breakpoint outside that block and another inside, it will stop on the breakpoint outside the block, then manage to stop on the breakpoint inside. It's a pretty bizarre bug.

I tried re-installing the Python interpreter, as well as PyCharm and still the behavior is the same.

EDIT:

I noticed that adding an empty if __name__ == 'main' block (with a pass instruction) in addition to the one with my logic makes the breakpoint work.

If I have to guess it has to do with some optimization that decides when breakpoints should trigger.

Avihooi Breakpoints inside `if __name__ == '__main__'` block works correctly for me. Could you please check if the issue is reproduced in a new project?

Andrey Resler I tried already and it works (I guess I should have mentioned it was only in my project). However, I will try to minimize the reproduction of the bug and post here my findings.

Avihooi Thanks,

Also, chances are that removing/renaming `.idea` directory from the project root while PyCharm is closed is going to help, but you'll need to recreate run configurations.

It would be great if you could provide a minimal reproducer, so we could investigate further.

Andrey Resler

Deleting the `.idea` directory had no effect. In fact, running the same code in a completely different project yielded the same bug which implies the bug is related to the code itself and not the environment.

However, I wasn't able to minimize the code to re-create the bug. It seems that removing single lines from the if __name__ == '__main__' block causes the breakpoint to work. Adding a breakpoint after the initial breakpoint causes the breakpoint to work. Removing some decorator in a class outside of that block causes the breakpoint to work.

As you can see, a couple of stars have to align for this bug to appear and I can't seem to find any discernible pattern.

Unfortunately, I can't share my code here publicly as it's code related to my work. What I can do however, if you or anyone from JetBrains is interested is to do a live session to demonstrate this bug and I can also perhaps give you the code privately.

I've been dealing with this problem for at-least 2 years now with specifically docker-compose debugging; it seems to effect numerous JetBrains products not just PyCharm.

By far the biggest problem is that this so PAINFULLY not tracked properly by JetBrains as a bug.

The problem can be hard to reproduce; many of the bugs relating to it have been closed and reference other non-related issues.

This problem is so deep and nested, and scattered everywhere I'm not sure how I can help at this point.

There is no centralized resource for help, tracking, and status of this bug.

The problem was introduced in Pycharm 2019.3

Release notes can be found here:

https://youtrack.jetbrains.com/articles/PY-A-154927105/PyCharm-20193-Release-Notes

A number of changes were made to the debugger that caused this. It would behoove IntelliJ to re-evaluate the changes made in the changelists denoted in youtrack for this release.

If you search for 'debug' on that youtrack page you can see quite a few modifications that clearly are responsible for this problem.

We confirmed this version was the introduction of the issue by installing multiple releases one after another and walking backwards until we found a release that properly stopped on our breakpoints.  The code fails on breakpoints in 2019.3, and succeeds in 2019.2.6.

Unfortunately, it's not code we can share with IntelliJ due to IP reasons.

At this point we don't take any updates to our PyCharm and run strictly .2.6 without any debugging issues.

It sucks to miss out on all the new features, but I'd rather have a working debugger than an improved font :/

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,

Martin

Martin Bammer2 Thank you for the feedback.

Is there any chance you could create a sample project where the issue can be reproduced? 

If not, then could you please create a bug report at https://youtrack.jetbrains.com/issues/py and provide the following:

Please add `PYCHARM_DEBUG=True` environment variable to your run/debug configuration, reproduce the issue and provide the full debug console output. Please also indicate the file path and line on which the non-functional breakpoint is set.

i can confirm that this is still an issue as well.

I'm on version PyCharm 2022.1.2 (Professional Edition) and everything works until a few days ago.

i didn't perform any system update or version update.

I'm debugging a local docker django app and sometimes it will work when I turn off the `Gevent compatible option for python debugger but then it takes a very long time to see variables or evaluate expressions (sometimes timing out).

I sort of got somewhere with Avihooi's comment, but then it failed again: I created a breakpoint in the left margin, then ran it - it skipped the breakpoint. Then I moved the breakpoint one line down (remove + add breakpoint in left margin), and then it suddenly stopped at the new breakpoint. But it didn't want to step into subsequent methods, so it's still useless.

I have tried everything else on this thread and nothing works. If this doesn't get solved soon, I'm moving over to VSCode like the rest of my team. I'm the only one left on PyCharm, and I got the Pro version specifically for WSL, which was so buggy that I switched to running PyCharm Pro for Linux, exposed as via X-Server to Windows. The other Pro feature that is useful is first-class Django support, but if debugging doesn't work, that's a moot point.

PyCharm 2021.2 (Professional Edition)
Build #PY-212.4746.96, built on July 27, 2021
You have a perpetual fallback license for this version.
Subscription is active until August 22, 2023.
Runtime version: 11.0.11+9-b1504.13 amd64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o.
Linux 5.4.72-microsoft-standard-wsl2

Hello everyone!

I'm facing the same issue mentioned previously.

For 2 weeks now, I had just updated my PyCharm.

PyCharm 2022.2.1 (Professional Edition)
Build #PY-222.3739.56, built on August 16, 2022
Runtime version: 17.0.3+7-b469.37 amd64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o.
Linux 5.15.0-47-generic
GC: G1 Young Generation, G1 Old Generation
Memory: 8192M
Cores: 12
Current Desktop: ubuntu:GNOME

I'm trying to debug custom Odoo modules inside a docker container.

I've created the Python Interpreter using the JetBrain way. I've also created a Python configuration. My paths mapping seem good.

Only the main file and some subfolders are able to be stopped with the integrated breakpoint on the left panel.

To be able to stop de process inside the other subfolders, I've to use the "breakpoint()" function and I've got a new window that helps me to define the path-mapping.

It's really weird and annoying to lose precious time for this kind of problem.

Sfa

Debugging odoo sounds like a known issue https://youtrack.jetbrains.com/issue/PY-43474/Debugger-ignores-breakpoints-when-debugging-Odoo-app

Please support the issue with your vote. Feel free to follow and comment. 

A workaround could be using the debug server -- https://www.jetbrains.com/help/pycharm/remote-debugging-with-product.html#remote-debug-config

Hello @Andrey Resler,

It was me who opened this bug a long time ago. I had corrected the bug because it was simply a path-mapping problem because I had stupidly copied/pasted from Windows, but the paths differed notably in the separating character "\" instead of "/".

Here I have tested again, and the behaviour is really weird.

First of all, when I (re)check my interpreter (Ctrl+Alt+S --> Build/etc..), I have the impression that it doesn't retain the docker-compose file(s) nor the service it should track.

Then I get the following behavior:

I have a main folder "Main_Folder" in which the first executed python file is located, an equivalent of "main.py". Inside this file, which contains only a few lines, the breakpoint stops correctly.

I have another folder represented like this "Main_Folder/First_subFolder_A/Second_subFolder_A" inside which I have python files and there too, the breakpoints work.

On the other hand, I have another folder represented as "Main_Folder/First_subFolder_B" in which I have many subfolders containing python files and in these, no breakpoints work.

On the other hand, if I use the "breakpoint()" function built into python since version 3.7, my execution stops "correctly" and PyCharm offers me a meter to "reconcile" the file mapping.

I checked the mappings in my debug configuration and they are correct: they match the Volumes defined in my docker-compose.yml

Also, what is even stranger: when I completely remove the path-mappings and restart my execution, I have the same behaviour, as if my configuration did not take into account these parameters at all....

I'm busy reconfiguring everything on a windows environment to see if the same problem persists but it's really disabling...

Thanks in advance for your feedback.

Edit N°1 : I've tested on Windows and I have the same behaviour/issues.

Edit N°2 : The same behaviour is there with the fresh new 2022.2.2 version (Pro Edition)

Edit N°3 : The same behaviour is there with the fresh new 2022.2.3 version (Pro Edition)

Same happened to me, but it was because I had pytest-xdist installed and on my pytest settings it was specified "-n auto", even if I set it to "-n 1" Pycharm will not respect the breakpoint, the only workaround that I had was to remove the "-n" option so then PyCharm was respecting it.

It seems to be another bug but it has the same behaviour as this one.

I experienced this problem on Pycharm 2023.1. I used a docker-compose interpreter to run a pytest-based test suite with a debugger. Some breakpoints were being hit, but most of them were not. Interestingly the ones not being hit were in the 'tests' submodule, whereas the ones working were in other non-test submodules. Hence, I suspect there might be something off about the jb_test_runner.

Anyway, here's the fix:

1. Add 'breakpoint()' anywhere in any module where breakpoints are not working

2. Run tests with a debugger

3. Now all breakpoints are being hit properly

4. Remove the 'breakpoint()' call - all breakpoints are still being hit properly even after multiple restarts ¯\_(ツ)_/¯

Same issue as Marcelo, If I set it to "-n 1" Pycharm will not respect the breakpoint, the only workaround that I had was to remove the "-n" option so then PyCharm was respecting it.

Hi!
I got the same problem. At some point in my code breakpoints did not stop anymore.

I found this https://stackoverflow.com/questions/9486871/pydev-breakpoints-not-working extremely helpful to solve this issue.

I ran into a recursion and somehow the exception was eaten away.

Follow the guide above and you probalby willl find a solution.

I am having this issue in version - 2023.3.4. However, I fixed it by enabling --no-reload (Django project) which ignores the auto-reload after changing the code. So this should not be an expected solution. I found that python-3.10 seems to work but not with 3.11. Question link.