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(R) Core(TM) 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%

Are you using the Docker extension? If so then you may be running into microsoft/vscode-docker#3750 .

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.

Isaac Sears (@isears)

I can confirm all that Isaac Sears (@isears) reported on my end also - reverting to 2022.18.2 solved issues with the debugger not attaching to the remote process to debug

Brett Cannon (@brettcannon)

Brett Cannon (@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.

2022.20.0 also updated debugpy, so there was a potential bug involved there. But 2022.20.1 went out yesterday with a rollback to debugpy 1.6.3, so you can unpin the Python extension and see if it works again.

I'm going to transfer this to debugpy in case they know what's going on.

Can you share your launch.json config for this?

I confirm 2022.20.1 solves the problem, so as you say it might well be an issue with debugpy. I'll let you decide if you want to keep this open or not. Thx for your help!

Can you share your launch.json config for this?

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

Roberto Vespa (@wasphub)

Roberto Vespa (@wasphub) do you think you can provide the logs when running it in the case where it's failing?
-- I've investigated a bit but I couldn't reproduce it and I'm hoping the logs could help me find what's the actual issue there.

Please see: https://github.com/microsoft/debugpy/wiki/Enable-debugger-logs for details on collecting the debugger logs.

Pavel Minaev (@int19h)

I was able to reproduce it by setting the wrong clientOS... I was reviewing the code and one thing that stood out which could affect this is that the client os is expected to be passed on the launch config -- previously this was already the case, but the default value was computed in the adapter.

i.e.: in 1.6.3, we have the following code to set the ide OS: https://github.com/microsoft/debugpy/blob/v1.6.3/src/debugpy/adapter/clients.py#L266 whereas in 1.6.4 this code is no longer in the adapter and was moved to the server (where the client is expected to set the clientOS from the arguments passed: https://github.com/microsoft/debugpy/blob/v1.6.4/src/debugpy/_vendored/pydevd/_pydevd_bundle/pydevd_json_debug_options.py#L100).

Now, in this particular case the adapter appears to be spawned in the client so, it got the client OS properly, whereas the new code will use the client OS as the same one in the server by default... note that this was probably already a latent bug we had because if the adapter was started on the server through a listen with a remote attach to the port it'd fail even in 1.6.3.

The solution I see here is that the client (in this case vscode-python) should pass the proper clientOS in the launch or attach arguments (since the client always knows where it's running, whereas the adapter may do the right thing or not depending on where it's started).

Pavel Minaev (@int19h) Karthik Nadig (@karthiknadig) do you think that's reasonable?

If that's the case this needs to be moved to vscode-python so that the clientOS is properly sent in the launch/attach.

As a note, users can already use a work-around by setting "clientOS": "Windows" in the launch configuration (or "clientOS": "Unix" if it's the other way around).

Roberto Vespa (@wasphub) can you install the v2022.20.0 version and check if it works if you set "clientOS": "Windows" in your launch configuration (just to make sure this is actually the issue you're seeing and whether it fixes it for you?)

Paula (@paulacamargo25)

/cc Paula (@paulacamargo25)

We need to set clientOS flag in all scenarios (launch and attach) in the debugOptions.

Set clientOS debug option (#20805)

Set clientOS debug option (microsoft#20805)

Cherry-pick: Set clientOS debug option (#20818)

We need to set clientOS flag in all scenarios (launch and attach) in the debugOptions.

Hey, I'm running into this issue when upgrading to v2023.4.1 or the latest v2023.6.0

I'm getting the following error when trying to attach to a remote process using the following configurations

Error:
pydev debugger: unable to find translation for: "d:\vscode-init\debuger-test\main.py" in ["D:\vscode-init\debuger-test/", "D:\vscode-init\debuger-test"] (please revise your path mappings).

Launch.json

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Debug",
            "type": "python",
            "request": "attach",
            "clientOS": "windows",
            "connect": {
                "host": "localhost",
                "port": 5678
            },
            "pathMappings": [
                {
                    "localRoot": "${workspaceRoot}",
                    "remoteRoot": "/app"
                }
            ]
        }
    ]
}

Environment Information:

Windows 10 Enterprise
vscode-python v2023.4.1

NOTE: It works with/without using "clientOS": "windows" when using v2023.4.0

Ronit Jain (@rjra2611)

Ronit Jain (@rjra2611) I created microsoft/debugpy#1257 on debugpy, please follow up there on this issue.

Merged PR posit-dev/positron-python#58: Merge latest upstream

Navigation Menu

Repository navigation

Debugging inside a container: debugger does not hit breakpoints anymore #20407

Behaviour

Expected vs. Actual

Steps to reproduce:

Diagnostic data

24 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Debugging inside a container: debugger does not hit breakpoints anymore #20407

Description

Behaviour

Expected vs. Actual

Steps to reproduce:

Diagnostic data

Activity

brettcannon commented on Dec 12, 2022

isears commented on Dec 12, 2022

janickm commented on Dec 13, 2022

wasphub commented on Dec 13, 2022

brettcannon commented on Dec 13, 2022

int19h commented on Dec 13, 2022

wasphub commented on Dec 14, 2022

wasphub commented on Dec 14, 2022

fabioz commented on Dec 15, 2022

fabioz commented on Dec 15, 2022

brettcannon commented on Dec 15, 2022

24 remaining items

paulacamargo25 commented on Mar 6, 2023

rjra2611 commented on Apr 3, 2023

karthiknadig commented on Apr 3, 2023

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions