sourceFileMap not working when using WSL

[trogne]

When debugging using gdb, on WSL ubuntu, I get this error :

Unable to open 'ioputs.c': Unable to read file 'vscode-remote://wsl+ubuntu/build/glibc-eX1tMB/glibc-2.31/libio/ioputs.c' (Error: Unable to resolve non-existing file 'vscode-remote://wsl+ubuntu/build/glibc-eX1tMB/glibc-2.31/libio/ioputs.c').

I get this error even with sourceFileMap defined below.

I can make debugging work if I make a symlink from "/build/glibc-eX1tMB" "/usr/src/glibc".

So it seems that the "sourceFileMap" does not work here.

I first add an issue for the C/C++ extension, but a comment mentioned that it could be an issue with vscode remote :
microsoft/vscode-cpptools#7389

  {
    "name": "(gdb) Launch",
    "type": "cppdbg",
    "request": "launch",
    "program": "${workspaceFolder}//${fileBasenameNoExtension}",
    "stopAtEntry": false,
    "cwd": "${workspaceFolder}",
    "environment": [],
    "externalConsole": false,
    "MIMode": "gdb",
    "miDebuggerPath": "/usr/bin/gdb",
    "setupCommands": [
      {
        "description": "Enable pretty-printing for gdb",
        "text": "-enable-pretty-printing",
        "ignoreFailures": true
      }
    ],
    "sourceFileMap": {
      "/build/glibc-eX1tMB": "/usr/src/glibc"
    },
  },

OS and Version: Windows 10
VS Code Version: 1.55.2
C/C++ Extension Version: v1.3.0

[weinand]

I'm not convinced that this is a VS Code issue. Please see microsoft/vscode-cpptools#7389 (comment)

[i-am-david-fernandez]

For what it's worth, I seem to be having the same problem (or at least, the same symptom) trying to debug a python app in a container via remote-ssh (i.e., Windows VSCode -> Linux VM via remote-ssh -> python app in docker container).

I get this:

Unable to open 'views.py': Unable to read file 'vscode-remote://ssh-remote+vm-hostname/app/b/views.py'
(Error: Unable to resolve nonexistent file 'vscode-remote://ssh-remote+vm-hostname/app/b/views.py').

I've changed some hostname/path details but they shouldn't matter.

I realise I'm using a completely different debugger (debugpy), and a different remote mechanism (ssh) but the symptoms suggest a common root cause. I cannot get path mappings to have any effect (I've tried using both pathMappings and sourceFileMap), but if I create an appropriate symlink within the VM (such that the absolute path to views.py in the container matches that within the VM, via the symlink), then things seem to work fine.

To clarify, I am connecting (remote-ssh) vscode to the VM and have the source on the VM (say at /home/user/my-app), and the container (via a docker-compose stack) is referencing the exact same source via a mounted volume, but it is at a different location within the container (say at /app). Creating a symlink on the VM /app -> /home/user/my-app allows things to work, but path/source mappings don't seem to have any visible affect.

I've tried a bunch of variations with the source/path mapping, but I don't think any have had any affect; even when using intentionally wrong local paths, the error message doesn't change (i.e., the wrong path doesn't appear in the message), suggesting that whatever I'm doing with the path mapping is being ignored (maybe hinting that I haven't got the remote side correct in order for replacement to occur??).

The use of a symlink might be workable short-term, but I'd really like this to work properly, as it opens up great opportunities for dev/debugging more broadly.

[weinand]

@i-am-david-fernandez please note that "path/source mappings" like the "sourceFileMap" property in the launch config from above are private properties of the debugger you are using. VS Code knows nothing about them, and even if they have similar names for different debuggers, their implementation is totally unrelated. A property "sourceFileMap" for the gdb debugger does not mean that the Python debugger provides the same. If you see squigglies in the launch.json, then this means that the use of the property has a problem.

[i-am-david-fernandez]

@weinand Thank-you for such a rapid response.

I must admit that I did (do) not understand how the different parts (pydebug, remote-ssh, python extension) worked together, and somewhat assumed that the remote extension was, as a kind-of middle-man, responsible for the translation. I'm still not certain whether you mean the "application-end" debugger (pydebug in my case) or the "code-end" debugger (the VS Code python extension) performs the mapping.

Whichever, you've clarified that my problem does not lie with the remote extension.

Edit: @weinand Thanks to your comment, I've found what I think is the root cause of my problem: microsoft/vscode-python#14820 Thank-you for helping me find it!