Debugging inside a container: debugger does not hit breakpoints anymore

[wasphub]

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:

1. Configure a project to run and debug inside a container
2. Set some breakpoints
3. Run the project
4. 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%

[brettcannon]

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

[isears]

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.

[ph03]

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

[wasphub]

@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.

[brettcannon]

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.

[int19h]

Can you share your launch.json config for this?

[wasphub]

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!

[wasphub]

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"
            }
        }
    ]
}

[fabioz]

@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.

[fabioz]

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).

@int19h @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).

@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?)

[brettcannon]

/cc @paulacamargo25