vscode-python: Debugging inside a container: debugger does not hit breakpoints anymore

Type: Bug

Behaviour

Expected vs. Actual

Context: Debugging code inside a container

Expected: breakpoint are hit when code is executed. Actual: breakpoints are not hit, and when the debug session the Debug Console shows:

pydev debugger: unable to find translation for: "c:\dev\qxc\model-sample\qxc\app\run.py" in ["C:\dev\qxc\model-sample/qxc/", "C:\dev\qxc\model-sample/qxc"] (please revise your path mappings).

Worth mentioning: rolling back to version v2022.18.2 of the extension fixes the problem without any change in the path mappings. Those mappings were defined weeks ago, and just stopped working with the latest release.

Steps to reproduce:

Configure a project to run and debug inside a container
Set some breakpoints
Run the project
Observe the warning describe above in the Debug Console, and verify that breakpoints are not hit

What seems strange from the message above is that the path inside the container c:\dev\qxc\model-sample\qxc\app\run.py looks like a Windows path, but the container I’m running is from a Linux-based image. I’m on a Windows box with Docker Desktop on WSL2.

Diagnostic data

Python version (& distribution if applicable, e.g. Anaconda): 3.7.4
Type of virtual environment used (e.g. conda, venv, virtualenv, etc.): Global
Value of the python.languageServer setting: Default

Output for Python in the Output panel (View→Output, change the drop-down the upper-right of the Output panel to Python)

XXX

User Settings


languageServer: "Pylance"

Extension version: 2022.18.2 VS Code version: Code 1.74.0 (5235c6bb189b60b01b1f49062f4ffa42384f8c91, 2022-12-05T16:38:16.075Z) OS version: Windows_NT x64 10.0.19044 Modes: Sandboxed: No

System Info

Item	Value
CPUs	Intel® Core™ i7-8650U CPU @ 1.90GHz (8 x 2112)
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_renderer: enabled_on video_decode: enabled video_encode: enabled vulkan: disabled_off webgl: enabled webgl2: enabled webgpu: disabled_off
Load (avg)	undefined
Memory (System)	31.86GB (11.04GB free)
Process Argv	–folder-uri file:///c%3A/dev/qxc/model-sample --crash-reporter-id d3ea3600-8e75-4ca7-a1d1-6a498426b4ab
Screen Reader	no
VM	0%

About this issue

Original URL
State: closed
Created 2 years ago
Reactions: 1
Comments: 35 (5 by maintainers)

Commits related to this issue

Set clientOS debug option (#20805) Closed: https://github.com/microsoft/vscode-python/issues/20407 — committed to microsoft/vscode-python by paulacamargo25 a year ago
Set clientOS debug option (#20805) Closed: https://github.com/microsoft/vscode-python/issues/20407 — committed to karthiknadig/vscode-python by paulacamargo25 a year ago
Cherry-pick: Set clientOS debug option (#20818) Closed: https://github.com/microsoft/vscode-python/issues/20407 --------- Co-authored-by: paulacamargo25 <paulitacv25@gmail.com> — committed to microsoft/vscode-python by karthiknadig a year ago

Most upvoted comments

@rjra2611 I created https://github.com/microsoft/debugpy/issues/1257 on debugpy, please follow up there on this issue.

karthiknadig on Apr 3, 2023

I’m having a similar issue. I run a aws python lambda image on docker, the debug is being attached but the code doesn’t stop in the breakpoints 😕

retatu on Feb 7, 2023

I confirm that adding "clientOS": "Windows" fixes the issue even with v2022.20.0. The clientOS attribute is underlined with a squiggly by VS Code, but it does work.

wasphub on Dec 16, 2022

{
    "configurations": [
        {
            "name": "App Local",
            "type": "docker",
            "request": "launch",
            "preLaunchTask": "docker-run-app-local",
            "clientOS": "Windows", 
            "python": {
                "pathMappings": [
                    {
                        "localRoot": "${workspaceFolder}/qxc",
                        "remoteRoot": "/qxc",
                    }
                ],
                "projectType": "general"
            }
        }
    ]
}

fabioz on Dec 16, 2022

@brettcannon I do use the Docker extension, but it seems to me it’s unrelated to the issue. As others posted, reverting to 2022.18.2 solves it, and it’s been working fine for weeks until the upgrade to 2022.20.0. Also, the issue you mention shows side effect I do not experience, like the code not running at all, in my case the code runs normally from the container, only breakpoints are not hit.

wasphub on Dec 13, 2022

I have encountered a similar issue, but using remote debugger features without docker. After reading this SO post I solved the issue by reverting from 2022.20.0 to 2022.18.2.

Seems like whatever broke back then broke again in the latest 2022.20.0

Note: it seems like the debugged program actually halts at the breakpoint, but it’s never registered on the clientside within VScode (i.e. no debug control panel pops up as you would normally expect). Once I detach from the debugged process execution continues as normal and I can see output.

isears on Dec 12, 2022