Vscode-cpptools: VSCode cannot open files when hitting breakpoints in debug (WSL)

[tabedzki]

I have searched for other things before posting. The markdown file for WSL with VSCode CPP debugging is useful but it doesn't contain an example for the launching when using code that is store in WSL and debugging it from there.

Describe the bug

• OS and Version: Windows_NT x64 10.0.17134
• VS Code Version: 1.30.2 (system setup)
• C/C++ Extension Version: 0.21.0-insider2
• The extension tries to open the file but cannot find it.

Additional context
I launch a debugging session to try and debug an executable compiled on the WSL using the following snippet from my launch.json. The debugging sessions starts and I see output that the code is supposed to output. However, I reach a segmentation fault and VSCode tries to open the file grid_utils.cpp where the fault is happening but can't. When I hover over the file name in the tab, I get just grid_utils.cpp but when I hover over other files from the same category, I get the whole path, e.g., C:\Users\Chris\AppData\Local\lxss\root\code\dmft-lc\main.cpp. I don't know how to make VSCode find the correct directory. The Linux path to the folder is /root/code/dmft-lc/ and the path in Windows is C:\Users\Chris\AppData\Local\lxss\root\code\dmft-lc. Let me know if anything is wrong or if more information is needed.

tasks.json:

            "name": "C++ Launch",
            "type": "cppdbg",
            "request": "launch",
            "program": "/root/code/dmft-lc/debug",
            "args": [
                "-fThreading"
            ],
            "stopAtEntry": false,
            "cwd": "/root/code/dmft-lc",
            // "cwd": "${workspaceRoot}/", // leave it like this
            "environment": [],
            "externalConsole": true,
            "windows": {
                "MIMode": "gdb",
                "setupCommands": [
                    {
                        "description": "Enable pretty-printing for gdb",
                        "text": "-enable-pretty-printing",
                        "ignoreFailures": true
                    }
                ]
            },
            "pipeTransport": {
                "pipeCwd": "",
                "pipeProgram": "c:\\windows\\sysnative\\bash.exe",
                "pipeArgs": [
                    "-c"
                ],
                "debuggerPath": "/usr/bin/gdb"
            },
            "sourceFileMap": {
                "/mnt/c/": "C:\\",
                "/root": "{LOCALAPPDATA}/lxss/root",
            }
        },

c_cpp_properties.json:

{
    "configurations": [
        {
            "name": "Linux",
            "includePath": [
                "${workspaceFolder}/**",
                "/usr/src/linux-headers-4.15.0-30/arch/x86/include/asm/",
                "/usr/src/linux-headers-4.15.0-30/include",
                "/usr/src/linux-headers-4.15.0-30/arch/x86/",
                "/usr/src/linux-headers-4.15.0-29/include/linux/",
                "/usr/src/linux-headers-4.15.0-30/include/linux/",
                "/usr/lib/x86_64-linux-gnu/openmpi/include/",
                "/usr/include/linux/",
                "${HOME}/Install",
                "/home/chris/.hidden-installs/Eigen-3.3.5"
            ],
            "defines": [],
            "compilerPath": "/usr/bin/clang",
            "cStandard": "c11",
            "cppStandard": "c++17",
            "intelliSenseMode": "clang-x64"
        }
    ],
    "version": 4
}

Output from the debugger

angles initialized
Found particles on proc 0!
Exchanged ghost particles!
Initial orientation properties calc'd  << Last expected line from my code

Thread 1 "debug" received signal SIGSEGV, Segmentation fault.
0x000000000045796d in charge_grid () at grid_utils.cpp:58
58      rho[4][i] = rholc[i] ;
Execute debugger commands using "-exec <command>", for example "-exec info registers" will list registers in use (when GDB is the debugger)
Stopping due to fatal error: NotImplementedException: No handler implemented for request type 'SourceRequest'!

[WardenGnaw]

In sourceFileMap can you replace {LOCALAPPDATA} with the full path?

E.g. C:\Users\Chris\AppData\Local

[tabedzki]

Sometimes it's the smallest thing. Thank you!
For completeness (and future browsers), here is the launch command that works:

Note: Updated to include @bobbrow's suggestion.

        {
            "name": "C++ Launch",
            "type": "cppdbg",
            "request": "launch",
            "program": "/root/code/dmft-lc/debug",
            "args": [
                "-fThreading"
            ],
            "stopAtEntry": false,
            "cwd": "/root/code/dmft-lc",
            // "cwd": "${workspaceRoot}/", // leave it like this
            "environment": [],
            "externalConsole": true,
            "windows": {
                "MIMode": "gdb",
                "setupCommands": [
                    {
                        "text": "-enable-pretty-printing",
                        "description": "enable pretty printing",
                        "ignoreFailures": true
                    },
                    {
                        "text": "handle SIGPIPE nostop noprint pass",
                        "description": "ignore SIGPIPE",
                        "ignoreFailures": true
                    }
                ]
            },
            "pipeTransport": {
                "pipeCwd": "",
                "pipeProgram": "c:\\windows\\sysnative\\bash.exe",
                "pipeArgs": [
                    "-c"
                ],
                "debuggerPath": "/usr/bin/gdb"
            },
            "sourceFileMap": {
                "/mnt/c/": "C:\\",
                "/root": "${env:LOCALAPPDATA}/lxss/root",
            }
        },

[bobbrow]

Does it work with ${env:LOCALAPPDATA}? There's a special syntax for environment variables if you don't want to use absolute paths.

[tabedzki]

Hey Bob, that does work. I'll update the previous comment to include it. Do you also know how to get it so that the ${workspaceRoot} works? Currently that variable is the windows path (C:\Users\tabedzki\AppData\Local\lxss\root\code\dmft-lc\). From my understanding, there is something called wslpath in WSL but I do not know if that is something that could be combined with this to yield a simpler solution than the full explicit path.

[crioux]

This is still broken on latest Insiders, as of today. I can reproduce it reliably. (running on Linux x86_64, installed via the apt repo)

Here's the debug configuration :

    {
      "name": "Debug",
      "type": "cppdbg",
      "request": "launch",
      "program": "${env:HOME}/foo/artifacts/bar",
      "miDebuggerServerAddress": "172.17.0.2:9091",
      "cwd": "${env:HOME}/foo",
      "linux": {
        "MIMode": "gdb"
      },
      "osx": {
        "MIMode": "gdb"
      },
      "windows": {
        "MIMode": "gdb"
      },
      "sourceFileMap": {
        "/root/src": "${homedir}/foo"
      }
    },

This is happening with local source code available in ${homedir}/foo, connecting to a remote gdbserver with no special options.

Click on an item in the call stack list to open the source file and this is what you get:

Thread 1 "bar" received signal SIGPIPE, Broken pipe. 0x00007ffff7fb5b87 in write () from target:/lib/x86_64-linux-gnu/libpthread.so.0 Execute debugger commands using "-exec <command>", for example "-exec info registers" will list registers in use (when GDB is the debugger) Stopping due to fatal error: NotImplementedException: No handler implemented for request type 'SourceRequest'!

It works if the source file map is only using absolute paths. But as soon as i try to use the ${homedir} variable things don't work.