Just my code not working in VS code

[irm-codebase]

Redirected from #224487

Type: Bug

As the title says: when I set a launch.json file and try to debug my code (selecting "with launch.json", VScode returns:

[Errno 2] No such file or directory: 'home/[myusername]/.local/lib

This is making debugging code outside mine (justMyCode=false) impossible, and is very annoying. What's going on?

Note: I use conda, and I have correctly selected my interpreter to be conda.

VS Code version: Code 1.91.1 (f1e16e1e6214d7c44d078b1f0607b2388f29d729, 2024-07-09T22:08:12.169Z)
OS version: Linux x64 6.9.11-200.fc40.x86_64
Modes:

System Info

Item	Value
CPUs	13th Gen Intel(R) Core(TM) i7-13700H (20 x 400)
GPU Status	2d_canvas: enabled canvas_oop_rasterization: disabled_off direct_rendering_display_compositor: disabled_off_ok gpu_compositing: enabled multiple_raster_threads: enabled_on opengl: enabled_on rasterization: enabled raw_draw: disabled_off_ok skia_graphite: disabled_off video_decode: enabled video_encode: disabled_software vulkan: disabled_off webgl: enabled webgl2: enabled webgpu: disabled_off
Load (avg)	1, 1, 1
Memory (System)	15.25GB (8.81GB free)
Process Argv
Screen Reader	no
VM	0%
DESKTOP_SESSION	gnome
XDG_CURRENT_DESKTOP	GNOME
XDG_SESSION_DESKTOP	gnome
XDG_SESSION_TYPE	wayland

Extensions (32)

Extension	Author (truncated)	Version
markdown-mermaid	bie	1.23.1
catppuccin-vsc	Cat	3.15.0
catppuccin-vsc-icons	Cat	1.13.0
ruff	cha	2024.36.0
file-tree-to-text-generator	d-k	1.4.0
vscode-markdownlint	Dav	0.55.0
EditorConfig	Edi	0.16.4
remotehub	Git	0.62.0
vscode-drawio	hed	1.6.6
compareit	in4	0.0.2
mypy	mat	0.3.1
rainbow-csv	mec	3.12.0
git-graph	mhu	1.30.0
debugpy	ms-	2024.8.0
python	ms-	2024.13.2024073102
vscode-pylance	ms-	2024.7.1
jupyter	ms-	2024.6.0
jupyter-keymap	ms-	1.1.2
jupyter-renderers	ms-	1.0.19
vscode-jupyter-cell-tags	ms-	0.1.9
vscode-jupyter-slideshow	ms-	0.1.6
remote-ssh	ms-	0.112.0
remote-ssh-edit	ms-	0.86.0
azure-repos	ms-	0.38.0
remote-explorer	ms-	0.4.3
remote-repositories	ms-	0.40.0
autodocstring	njp	0.6.1
vscode-yaml	red	1.15.0
snakemake-lang	sna	0.1.8
code-spell-checker	str	3.0.1
code-spell-checker-british-english	str	1.4.10
even-better-toml	tam	0.19.2

[irm-codebase]

setting "debugpy.debugJustMyCode": false is the cause of the issue. Basically:

• debugJustMyCode: true ---> the debugger works fine (breakpoints are reached, etc)
• debugJustMyCode: false ---> the debugger stops working at all, reaching the Errno 2 state.

[irm-codebase]

Configuration used:

{
    // 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 Debugger: Current File",
            "type": "debugpy",
            "request": "launch",
            "program": "${file}",
            "console": "integratedTerminal",
            "justMyCode": false
        }
    ]
}

Error message seen:

[paulacamargo25]

Thanks for your bug report @irm-codebase, that was a bug in vscode related to justMyCode, can you try again and see if the error persist with the last version of vscode? Thanks

[irm-codebase]

@paulacamargo25 thanks for the help!

Tried with the config below. Errno 2 no longer happens... but justMyCode is ignored despite setting it to false in both launch.json and settings.json. I could not reach a random breakpoint I placed in the geopandas library.

VSCode is telling me that those settings are not being checked:

Is this another, separate issue?

launch.json config:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Python Debugger: Current File",
            "type": "debugpy",
            "request": "launch",
            "program": "${file}",
            "console": "integratedTerminal",
            "justMyCode": false
        }
    ]
}

settings.json:

{
    "debugpy.debugJustMyCode": false
}

[irm-codebase]

Also, small little rant: VSCode has been... pretty bad to work with lately.
Lots of little bugs like this everywhere, constant breaks and instability.

Obviously not the fault of the folks helping with this issue, but it's just... kind of a bad IDE to work with at the moment. At least for python...

[vs-code-engineering]

Hey @karthiknadig, this issue might need further attention.

@irm-codebase, you can help us out by closing this issue if the problem no longer exists, or adding more information.

[irm-codebase]

@karthiknadig since the bot asked... this bug is till present in the newest VSCode version.
Setting justMyCode to false results in errno2

[karthiknadig]

The justMyCode issue here seems like something internal to debugpy. Move to debugpy for more investigation.

[rchiodo]

This works for me. I used this code here:

import pytest

def test_justmycode():
    pytest.skip("test_justmycode is not implemented yet.")

test_justmycode()

Then I stuck a breakpoint in this file:

.venv\Lib\site-packages_pytest\outcomes.py

The breakpoint hit when running with justMyCode=false.

Can you try that same repro? It might be a path mapping problem. The file you have with the 3rd party code is not the path that debugger is finding.

[irm-codebase]

@rchiodo just to be clear on this: was your question directed at me? or at other maintainers tackling this issue?
In my case I am using conda, so I cannot reproduce your use case.

[irm-codebase]

I repeated your test case with the following in my conda project.

1. script

import pytest

def test_justmycode():
    pytest.skip("test_justmycode is not implemented yet.")

test_justmycode()

2. settings

{
    "python.testing.pytestArgs": [
        "tests"
    ],
    "python.testing.unittestEnabled": false,
    "python.testing.pytestEnabled": true,
    "debugpy.debugJustMyCode": false
}

3. breakpoint

4. run debugger

5. fail

[rchiodo]

Okay it looks like it actually worked it's just the callstack isn't showing up. What's your version of VS code? There was a bug in VS code where they were hiding 'internal' stack frames (which these frames would be marked as).

This issue here:
microsoft/vscode#214433

I'd try updating to the latest VS code and see if the problem reproduces. It seems to work for me on 1.94.0-insiders and 1.93.1 stable

This is the callstack I get:

[irm-codebase]

@rchiodo apologies for the delay
I tried this in VSCode 1.94.2. Same error.

[rchiodo]

I still suspect a VS code issue. We can double check that we're sending the stack frames but this is the same symptoms as the bug I mentioned above.

If you turn this on:

"logToFile": true

In your launch.json. That will generate logs in your /home/<user>/.vscode/extensions/ms-python.debugpy-<version>/ folder. Those logs should contain the stack frame request and response. If they do, VS code isn't displaying it for some reason.

[irm-codebase]

It might be, but I am not a VScode nor a debugpy dev... so interpreting this is a tad difficult for me.
Originally, my issue was 'bounced' from vscode to debugpy, and that issue has been locked so I cannot re-open it.
What would be your suggestion to move this forward? Creating a new issue on the VSCode side?

I think I generated the log file successfully. Here is what it has at the bottom (just as a way to see if I'm in the right file):

1416 Client --> Adapter:
{
    "command": "stackTrace",
    "arguments": {
        "threadId": 1,
        "startFrame": 4,
        "levels": 19
    },
    "type": "request",
    "seq": 15
}
1420 Client <-- Adapter:
{
    "seq": 27,
    "type": "response",
    "request_seq": 15,
    "success": true,
    "command": "stackTrace",
    "body": {
        "stackFrames": [],
        "totalFrames": 4
    }
}

[rchiodo]

The log makes it look like debugpy isn't returning the stack frames. Can you upload all of the other log files from that run? The pydevd one might give us a clue as to why there's no stack frames listed there.

[irm-codebase]

Here it is!
debugpy.pydevd.9272.log

[rchiodo]

Hmm, doesn't make sense. It has a stack, but it doesn't return it. It returns it once but not the second time. Not sure why there's two threads shown either.

I think we'd need the code to reproduce the problem. Can you share the code that's causing this?

[irm-codebase]

It's the same code as the one you shared above.
However, all code fails. In all projects in my workstation.
Every case I try returns this issue if 'debugpy.debugJustMyCode' is False.

Here are some settings, and a project (https://github.com/calliope-project/ec_utils/tree/feature-modulegraph), although honestly I do not think the project will matter.

Script:

import pytest

def test_justmycode():
    pytest.skip("test_justmycode is not implemented yet.")

test_justmycode()

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 Debugger: Current File",
            "type": "debugpy",
            "request": "launch",
            "program": "${file}",
            "console": "integratedTerminal",
            "logToFile": true
        }
    ]
}

vscode settings (general)

{
    "workbench.colorTheme": "Catppuccin Mocha",
    "redhat.telemetry.enabled": false,
    "[python]": {
        "editor.defaultFormatter": "charliermarsh.ruff",
    },
    "git.autofetch": true,
    "cSpell.language": "en,en-GB",
    "cSpell.diagnosticLevel": "Hint",
    "jupyter.runStartupCommands": [
        "%load_ext autoreload",
        "%autoreload 2"
    ],
    "editor.fontFamily": "\"Fira Code\"",
    "editor.fontWeight": "normal",
    "editor.fontLigatures": true,
    "workbench.iconTheme": "catppuccin-mocha",
    "terminal.integrated.inheritEnv": false,
    "update.mode": "manual",
    "jupyter.askForKernelRestart": false,
    "jupyter.notebookFileRoot": "${workspaceFolder}",
    "jupyter.interactiveWindow.creationMode": "perFile",
    "window.restoreWindows": "none",
    "telemetry.telemetryLevel": "off",
    "ruff.nativeServer": true,
    "ruff.lint.ignore": [
        "PD004",
        "PD003"
    ],
    "mypy.debugLogging": true,
    "mypy.dmypyExecutable": "/home/ivanruizmanuel/miniforge3/bin/dmypy",
    "files.watcherExclude": {
        "**/.git/objects/**": true,
        "**/.git/subtree-cache/**": true,
        "**/node_modules/*/**": true,
        "**/.hg/store/**": true,
        "**/.snakemake/**": true
    },
    "search.exclude": {
        "**/node_modules": true,
        "**/bower_components": true,
        "**/*.code-search": true,
        "**/.snakemake": true
    },
    "markdownlint.config": {
        "MD007": {
            "indent": 4
        }
    },
    "ruff.configurationPreference": "filesystemFirst",
    "hediet.vscode-drawio.theme": "Kennedy"
}

vscode settings (project):

{
    "python.testing.pytestArgs": [
        "tests"
    ],
    "python.testing.unittestEnabled": false,
    "python.testing.pytestEnabled": true,
    "debugpy.debugJustMyCode": false
}

[rchiodo]

You must have 'raised exceptions' checked:

It's hitting those before it gets to the breakpoint. If you turn off that setting it should work.

VS code doesn't show non user code in those raised exceptions. You have to expand them:

I get this (if I enable raised exceptions):

If you want to see these frame you have to click on the 'show 3 more frames', but none of your code is in it.

This is what it will show if you click on the 'show 3 more frames'

[irm-codebase]

It is as easy as that, huh? The problem is gone.
Thank you very much for the help @rchiodo , and sorry for taking your time!

Just for my understanding: basically, this is a bunch of 'harmless' internal Python exceptions that are hit before our test code runs, correct? Honestly I was assuming that this was a bug caused by debugpy or VSCode forgetting the active environment or something.
This makes way more sense.

Thanks again!

[rchiodo]

this is a bunch of 'harmless' internal Python exceptions that are hit before our test code runs

Yes, that's correct. Lots of other spots in the runtime or pytest can throw and handle exceptions before or even during your test running.