I have community edition version 5.0.2 of PyCharm. My Python version is 2.7.
The problem is simple.
In the 'Run' mode everything works fine. But when I try to insert breakpoints and launch 'debugging' mode, it does not stop at breakpoints. However, corresponding debugging window is appearing and buttons to "resume", "stop" and "pause" are there. But if I try to "stop" or "pause" it does not take any effect. Program works like it is in 'run' mode.
C:\Python27\python.exe "C:\Program Files (x86)\JetBrains\PyCharm Community Edition 5.0.2\helpers\pydev\pydevd.py" --multiproc --qt-support --client 127.0.0.1 --port 56284 --file C:/Users/.../.../main.py
pydev debugger: process 8112 is connecting
Connected to pydev debugger (build 143.1184)
None
([], 75)
Process finished with exit code 0
What could it be? In other Intellij products (such as Intellij Idea) I did not encounter such a strange issue.
Could anybody help?
When I run a Django project in debug mode with Eclipse (and PyDev plugin) it stops in all the breakpoints correctly and I can inspect all the values of the environment variables, but when I try to write whatever in the console I get this error and it doesn't print anything else:
[Invalid Frame]: Please select frame to connect the console.
Humm, turns out this was a bug when debugging multiple processes in PyDev. I just fixed it in https://github.com/fabioz/Pydev/commit/e13fd81fe87365be54aed8405741f84df90f2fca.
It should be released on PyDev 4.5.0. In the meanwhile, as a workaround to have a console with such a connection you can right-click the stack (in the debug view) and select PyDev > Debug Console -- by doing so, you'll have an interactive console with a proper connection to that frame.
I had a similar problem while running on Windows 7 with Eclipse, nano and Pydev 5.2.
PYTHONPATH was set in Eclipse. But I expected that the variable was automatically set in the environment variables. But it's not the case.
I corrected it by following these steps:
Went to Advanced System Settings in Control Panel/All Control Panel Items/System/.
Entered into Environment Variables.
Added %PYTHONPATH% and the value of e.g. E:\blender-2.77-windows64\doc\python_api\pypredef; (Or where you have your python installation).
Added this variable to my system's PATH variable
I have a flask project I am trying to debug (this was working absolutely ok till few hours ago) - When I debug the project, I see the following :
Connected to pydev debugger (build 135.1057)
/Users/vantani/cp/bin/python /Applications/PyCharm.app/helpers/pydev/pydevd.py --multiproc --save-
signatures --client 127.0.0.1 --port 49223 --file /Users/vantani/cp/unnamed/manage.py server
pydev debugger: process 484 is connecting
/Users/vantani/cp/lib/python2.7/site-packages/flask_cache/__init__.py:152: UserWarning: Flask-
Cache: CACHE_TYPE is set to null, caching is effectively disabled.
warnings.warn("Flask-Cache: CACHE_TYPE is set to null, "
* Running on http://127.0.0.1:5000/
* Restarting with reloader
pydev debugger: process 498 is connecting
As I said this setup was working fine. Now, the debugger does not stop at the breakpoint and the debugger window is empty. I see that there are two processes created by PyDev and I guess that is causing this issue. I have restarted my machine and there is only one pycharm process running.
Sometimes this might be caused by the fact that some other module is using the same tracing api (sys.settrace) as debugger, for instance Coverage.py. The solution would be to go to your Rub/Debug Configurations and add --no-cov flag to the Additional Arguments.
Alternatively you might want to delete all --cov in pytest settings (i.e. pytest.ini) or run tests with --no-cov flag, i.e.
pytest test.py --no-cov
It might be also caused by a bad filename, e.g. your file/directory has special characters or spaces in it. Try removing them or changing to e.g. underscore (_).
There is an issue with the debugger in PyCharm lately.
I'm on mac using PyCharm 2020.2 and while the debugger would stop at tests, it wouldn't stop when running the dev server for django.
For me disabling Gevent compatible option in Preferences > Build, Execution, Deployment has helped.
Worth noting that some suggest to enable some suggest to disable that option - so it's worth having a go at each and see if that helps your case.
Just need set flask's debug mode off, such as
app.run(debug=False)
I didn't have a flask project but I had the same problem. In my case I had to change the project-path! There were umlauts (ü,ä,ö) in it. By removing them the breakpoints worked again.
My problem is solved when I installed pydevd-pycharm
pip install pydevd-pycharm
Also here is a useful link for this problem.
github from jetbrains intellij-community
Check your python debugger settings, and clear your cache, This helped me
The following workaround should help. I had a same problem in a simple Python script. PyCharm debugger didn't stop on a simple breakpoint and just ran to the end.
Thanks to Gabriel's answer, I checked the path to my script and it had Russian letters. Because I use Russian Windows and it creates admin user named 'Administrator' using Russian letters.
I changed the Russian letters to use only English letters from the project-path (just copied PyCharm projects folder to the root of disk and reloaded my project from new place. Nothing else was changed!). And the debugger immediately started working just fine and stopped on breakpoints!
It looks like this a bug that PyCharm debuger can't work with different national letters in the path. It very common situation outside English-speaking countries.
For Sanic case.
Run go_fast(..auto_reload=False,..).
There is a long thread about this issue on JetBrains forums:
https://intellij-support.jetbrains.com/hc/en-us/community/posts/360008107400-PyCharm-2020-1-not-stopping-on-breakpoints-anymore-. Reading through that thread is like reading a black magic book, everyone has their own voodoo $^$#
I ran into this issue with 2021.1.1 CE and a brand new project. My solution was to change the default test runner to pytest. YMMV. If that thread is any indication, debugging might stop working if it rains tomorrow.
For me I deleted project from "recent projects in pycharm" then I opened project direct from repository. It works again.
Had the same issue recently (July 2021 PyCharms 2021.1.3 CE) for days trying everything I could find online would not work. Then found under File --> Manage IDE Settings --> Restore Default Setting, that fixed the issue for me.
For all those people that have the same problem, but can't resolve it, maybe this will work:
The problem could be, that pydev isn't connecting to its subprocess.
Check if the option "Attach to subprocess automatically while debugging?" in the debugger settings is set. You can find it in File > Settings > Build, Execution, Deployment > Python Debugger (current version of PyCharm)
Usually there is also a short hint in the console but I didn't notice it.
After removing debug_toolbar middleware the debugger is back to normal.
It's happening because of a third party module. I tried all the solutions listed and none worked for me.
I changed the interpreter that I'm using and it's working.
I had this issue when running remote interpreter from docker-compose. It disappeared when I set Working directory to my project root directory in Run/Debug Configuration. I also restarted Pycharm and invalidated caches.
I got it fixed by removing coverage config from pytest.ini
Not exactly the same case but, if you are using the Debug Server to debug a docker container, the only thing which made the breakpoint to stop for me is to set and environment variable for the container:
PYCHARM_DEBUG=True
PyCharm Version: 2022.2.2
For me PyCharm actually executed a different file. If you just clicked the run button... try if it makes a difference if you use
right click on file => Run 'xy'.
Or double check if your file full path to be executed is specified in "Script path" in the run configuration. I used to use the file name in "interpreter option" along with "working directory" specified. It would work that way.
I am using Komodo IDE 7 with a Django 1.4 using Python27.
I have been using the remote debugging option of Komodo IDE 7 but it seems to not responed to my breakpoints. If I break in my model decleration/setting.py it does break for the first time but it seems to "disconnect" after the first initialization.
the command I am running the debugger is :
set KOMODO_PATH="%ProgramFiles%\ActiveState Komodo IDE 7\lib\support\dbgp\bin"
c:\python27\python %KOMODO_PATH%\pydbgp.py -d localhost:9000 manage.py runserver --noreload
Figured out that this is a bug in Komodo 7.02. It seems that Django 1.4 uses a multi-threading machanisim which doesnt work well with Komodo.
A bug was filed but for a while there is a work around : using --nothreading while starting manage.py.
However, it seems to effect performance badly !
I have got Pydev configured properly so it runs my app, however when I want to inspect/trace my code by setting up breakpoints the debugger does not kick in (can't trace). Does anyone got any idea what's going on here?
--noreload option is crucial, otherwise server will fork and your breakpoint won't trigger.
Ordinarily you wouldn't have to select manage.py and hit debug. From your description it sounds like you may not have set up the Django launch params in the Run/Debug settings panel.
Here are some step by step instructions:
http://pydev.blogspot.com/2006/09/configuring-pydev-to-work-with-django.html
and
http://developeradventures.blogspot.com/2008/03/eclipse-django-debugging.html
The important part is adding the entry to the Run/Debug settings. When it's time to debug, set the breakpoint, on the Eclipse toolbar click on the Debug button's drop-down arrow and select the Django project you've defined. Then from a browser window go to your Django server's URL. Eclipse should stop at the breakpoint.
Ok I think I found what my problem was. I had to set the breakpoint on the def statement in views.py instead of the statements after it.
If you're debugging the Django runserver, make certain you specify the --noreload command line parameter. Otherwise the debugger ends up looking at the wrong python instance and never trips any breakpoints.