65

I have just installed VS Code and the Python extension, and I have not been able to get the debugger to work. Every time I try to use the debugger, it just skips over any breakpoints that I have set and runs the program like normal.

I am using VS Code on a Windows 10 PC with Python 3.7.3 and the Python extension installed. I followed the instructions here (https://code.visualstudio.com/docs/python/python-tutorial) to make a test folder called 'hello' in C:\python_work\hello and create a program called 'hello.py' inside that folder. hello.py is shown below. I tried using the debugger both by pressing the green arrow and by pressing F5, but neither seemed to make the debugger work properly. My 'launch.json' file is also shown below.

hello.py:

msg = "Hello World!"
print(msg) # Breakpoint

launch.json:

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Python: Current File",
            "type": "python",
            "request": "launch",
            "program": "${file}",
            "console": "integratedTerminal",
            "stopOnEntry": true
        },
    ]
}

I expected the bottom bar to turn orange and the program to stop on the second line, allowing me to examine the local and global variables in the preview pane. Instead, the bottom bar stayed orange for 1/2 a second while the program ran as if I had pressed "Run Python File in Terminal," without stopping at the breakpoint. Please help!

rogo8888
  • 651
  • 1
  • 5
  • 4
  • It's working fine for me. What is being sent to the terminal to launch the debugger? – Brett Cannon Jun 27 '19 at 22:20
  • Something like this: `cd c:\python_work\hello && cmd /C "set "PYTHONIOENCODING=UTF-8" && set "PYTHONUNBUFFERED=1" && C:\Python\python.exe c:\Users\RohanPC\.vscode\extensions\ms-python.python-2019.6.22090\pythonFiles\ptvsd_launcher.py --default --client --host localhost --port 49389 c:\python_work\hello\hello.py "` – rogo8888 Jun 28 '19 at 13:23
  • If you could file a bug at https://github.com/microsoft/vscode-python and provide a GitHub project or zipfile of a folder that can reproduce the problem then we can have a look and see if we can figure out what's going on. – Brett Cannon Jun 28 '19 at 17:46
  • 2
    I just reinstalled Windows and the problem got solved! Thank you so much for your help. – rogo8888 Jul 02 '19 at 14:45
  • 80
    It's generally regarded as good practice to reinstall Windows at least twice a day. – kmiklas Jan 24 '20 at 00:00
  • On MacOS, "run->start debugging (F5)" sometimes does not stop at breakpoints. Assuming the Python module is run as a a script (ie, it contains a condition `if __name__ == "__main__": `), and in case a Python exception is hit during execution, then VS Code breaks with a pop-up message "Exception has occurred: System Exit" in the main section. At this point, click "run->restart debugging (shift-cmd-F5)" and voila': now breakpoints are hit. – caucus Aug 06 '22 at 09:17

12 Answers12

85

Setting "justMyCode": false makes it stop at breakpoint:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Python: Debug Current File",
            "type": "python",
            "request": "launch",
            "program": "${file}",
            "console": "integratedTerminal",
            "stopOnEntry": true,
            "justMyCode": false
        },
    ]
}
Bhargav Rao
  • 50,140
  • 28
  • 121
  • 140
Ashish
  • 999
  • 6
  • 4
  • 47
    this worked... how am I supposed to guess something like this? – Vland Aug 27 '20 at 15:09
  • 2
    weird that it's not "true" by default ! Another problem I'm facing now is, it doesn't end the debugging after execution of the last line. it goes into "runpy.py"... how should I fix this one? – S.B Mar 22 '21 at 10:05
  • 3
    Without resources like StackOverflow I don't think I'd ever have solved this. Just My Code is a set of features that makes it easier to focus on debugging your code by hiding some of the details of optimized libraries that you might be using, like the .NET Framework itself (says https://github.com/OmniSharp/omnisharp-vscode/blob/master/debugger-launchjson.md#just-my-code). But I'm running a program I wrote which contains a few simple lines, and no calls to any modules. Can anyone throw any light on why I need to turn this feature off? – Andy Brown Aug 14 '21 at 10:56
  • 2
    How do I find this file to make this edit? – Luke Schoen Apr 08 '22 at 23:57
  • On menu bar , click Run and then Open Configuration – Ashish Apr 10 '22 at 18:25
  • Yes, but it should work with this set to "true". justMyCode makes sure that Step In, etc go into your own code only, and not the code of the library you're importing. – Danyal Jul 19 '22 at 17:53
  • 1
    Clearly a bug in "justMyCode". – Nathan Chappell Oct 06 '22 at 07:30
  • true, seems like a bug, logically – Ashish Oct 07 '22 at 12:48
  • Doesn't work for me. Strangely, `stopOnEntry: true` does make the debugger stop at the start of the application, but all breakpoints further on are ignored. – Karolis Mar 01 '23 at 11:10
  • In my case, I had to set `django: true` too, because well… it's a django app. – Etienne Mar 01 '23 at 14:25
41

If you're using a pytest-cov module you might also wanna have a look at pytest configuration settings note:

Note If you have the pytest-cov coverage module installed, VS Code doesn't stop at breakpoints while debugging because pytest-cov is using the same technique to access the source code being run. To prevent this behavior, include --no-cov in pytestArgs when debugging tests, for example by adding "env": {"PYTEST_ADDOPTS": "--no-cov"} to your debug configuration.

See an example configuration file (launch.json) below:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Debug Tests",
            "type": "python",
            "request": "test",
            "console": "integratedTerminal",
            "justMyCode": false,
            "env": {"PYTEST_ADDOPTS": "--no-cov"}
        }
    ]
}
Tomasz Bartkowiak
  • 12,154
  • 4
  • 57
  • 62
  • 4
    This was exactly the problem I was facing too. I had this in my .vscode/settings.json: { "python.testing.pytestArgs": [ "--cov=src", "--cov-report", "html", "tests" ] // Removing the coverage related lines solved the problem. – Michael S Apr 03 '22 at 13:45
  • 2
    In my case, coverage was setup in my `setup.cfg` file. It worked by either removing it from that file or using Tomasz's `"env"` tip. Thank you! – BraisLP Jun 16 '22 at 11:35
  • 1
    VSCode highlights the line 'request': 'test' with a warning: `Request type of configuration. Can be "launch" or "attach". Value is not accepted. Valid values: "launch".` but it works anyway. – Alex Sep 08 '22 at 10:19
  • This has recently changed: https://code.visualstudio.com/docs/python/testing#_debug-tests. Need to add `"purpose": ["debug-test"]`. https://code.visualstudio.com/docs/python/debugging#_purpose – rdbisme Feb 01 '23 at 14:33
4

I experienced the same behaviour and was able to solve it by installing the virtual environment of Python in the following way:

[MyProjectFolder] \ venv

by entering the command

python -m venv [MyProjectFolder]\venv

in the console.

VS Code seems to expect exactly that folder structure.

Before I had installed the venv-folder-structure directly in my projects-folder, i.e.

[MyProjectFolder] \ Scripts
[MyProjectFolder] \ Lib
[MyProjectFolder] \ Include
[MyProjectFolder] \ pyvenv.cfg

which did not work and caused exactly the described debug problems.

just as a reference: VS Code version 1.52.1 and Python 3.8.5

  • This creates a .venv but doesn't allow me to select a venv interpreter – AlxVallejo Mar 05 '21 at 16:09
  • I don't think this has anything to do with the debug point issue. You can select the Python interpreter doing `CTRL+Shift+P` -> `Select Python Interpreter` -> `Enter interpreter path` – alelom Jun 23 '21 at 08:15
  • Thanks for this answer, the scripts lib include and pyenv.cfg should be removed before running the python -m venv command, install new venv format then restart vscode – Guillermo Ruffino Jun 29 '21 at 14:53
  • That did the trick for me! – sonntam Jul 22 '23 at 12:01
2

Downgrading from Python 3.9 to 3.8 worked for me.

VC Code 1.56.2 ignored breakpoints running Python 3.9 64-bit on Windows 10 version 20H2. Installing Python 3.8.10 64-bit fixed the problem. I just needed to select the Python 3.8.10 interpreter within VS code and it now recognizes breakpoints. No changes to the configuration file were needed, for example, I did not need "justMyCode": false

I realize this is an old question, but my google search lead me to it. Many of the previous answers no longer apply. So I'm posting this fix for others who land here in 2021 trying to use 3.9.

QueensDog
  • 31
  • 2
1

I had the same problem having upgraded from Python version 3.7 to version 3.9. I later found out that the old version was 32 bit, and the new version I upgraded to was 64 bit, which apparently caused the issues. Uninstalling the 64 bit version and installing the 32 bit version of Python 3.9 solved my problem, and I was then able to use the Visual Studio Code breakpoint functionality again.

  • This did not work for me. Went from Python 3.8.2 x64 to Python 3.7.8 x32 and debug points still do not work. – alelom Jun 23 '21 at 08:49
1

For everyone coming here looking for a solution related to breakpoints in python unittests:

  1. If not already done add a configuration file, i.e. launch.json, as described in the vscode python debugging tutorial.

  2. For me the following configuration settings worked, whereby setting cwd (because of src and test folders) and purpose (see also here) were essential.


"version": "0.2.0",
    "configurations": [
        {
            "name": "Python: Test Cases",
            "type": "python",
            "request": "launch",
            "cwd": "${workspaceFolder}/afinad/src",
            "purpose": [
                "debug-test"
            ],
            "console": "integratedTerminal",
        }
    ]

Happy debugging!

marcel h
  • 742
  • 1
  • 7
  • 20
1

Another source of no-breakpoints-working is elevate:

try: # https://pypi.org/project/elevate/
    from elevate import elevate
except ModuleNotFoundError: # install it if not found
    subprocess.call([sys.executable, "-m", "pip", "install", 'elevate'])
finally:
    from elevate import elevate

# require elevated permissions right away...
elevate()

The elevate() command restarts the program as a new (child) process, so the entire file becomes un-breakpoint-able. From the author:

On Windows, the new process’s standard streams are not attached to the parent, which is an inherent limitation of UAC.

In windows, to debug python applications in VS Code which need to be run as administrator, a work-around is this:

  1. Close VS Code.
  2. Right-click VS Code icon, choose "Run as Administrator."

Linux users could likely do the same with sudo code. Now the process will be spawned initially as administrator, so the call to elevate() does nothing and the whole file is debuggable.

rdtsc
  • 1,044
  • 10
  • 17
0

I recently found out ( 5th May 2020) that using Python 3.9 as interpreter the breakpoints were not hitting. Install 3.8 and it will start working again.

borcho
  • 137
  • 4
0

My issue was that I was putting the breakpoint on the line of the function declaration itself, so the def foo(x): line, instead of putting the breakpoint on the first non-comment line inside of the function.

If the first line of your function is a comment, the debugger will assume you meant to place the breakpoint on the line of the function declaration and move your breakpoint back, so really make sure you aren't placing your breakpoint on a comment!

MyNameIsTrez
  • 117
  • 2
  • 13
0

Another source of debugger not stopping at breakpoint: an homonym file, from another directory, is open in VS Code.

In fact, VS Code can set breakpoints on any Python file, even outside of your Python project's directory; if the path of the file does not match the one in launch.json, "program": [your-file-name-here] entry, then breakpoints are not hit.

For example: copies of Python source files are located under dist/lib, the output of setuptools (run: python setup.py bdist_wheel to generate them).

If dist/lib is not excluded through .gitignore, then its contents shows up in the search results sidebar and can be click open by mistake.

Caveat: the above does not hold if the launch.json configuration has "program": "${file}".

caucus
  • 182
  • 1
  • 10
0

I (re)downloaded VS Code again: https://code.visualstudio.com/ The breakpoint got to show up on hover and function with the Run and Debug for the python file I was working on.

Additionally, I had to solve a syntax error in my code before the debugger buttons (step over/in, etc) had to go through the code lines

Anna
  • 47
  • 6
0

I have been battling with this for the last hour, and it finally worked by renaming my python file from camelCase.py to snake_case.py

user819640
  • 250
  • 5
  • 14