Vscode-cpptools: Attach to WSL process not working due to bash.exe hanging

[ganibc]

Hi,

I read this tutorial: https://github.com/Microsoft/vscode-cpptools/blob/master/Documentation/Debugger/gdb/Windows%20Subsystem%20for%20Linux.md

The launch settings is working fine, but the attach settings give me this error in the output window:

The system cannot find the path specified.
Command failed: "c:\windows\sysnative\bash.exe" "-c" "bash -c 'uname && if [ $(uname) == "Linux" ] ; then ps -axww -o pid=,comm=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa,args= ; elif [ $(uname) == "Darwin" ] ; then ps -axww -o pid=,comm=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa,args= -c; fi'"
The system cannot find the path specified.

This is the launch.json file:

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "name": "C++ Launch",
            "type": "cppdbg",
            "request": "launch",
            "program": "/mnt/c/Projects/Linux/testbare/app",
            "args": [""],
            "stopAtEntry": false,
            "cwd": "/mnt/c/Projects/Linux/testbare",
            "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:\\"
            }
        },
        {
            "name": "C++ Attach",
            "type": "cppdbg",
            "request": "attach",
            "program": "/mnt/c/Projects/Linux/testbare/app",
            "processId": "${command:pickRemoteProcess}",
            "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:\\"
            }
        }
    ]
}

FYI, "app" is the executable name (just in case it's not clear).

Any idea where the problem is?
Thanks.

[WardenGnaw]

@ganibc Can you run C:\Windows\SysWow64\cmd.exe. And then in that shell can you run "c:\windows\sysnative\bash.exe" "-c" "bash -c 'uname && if [ $(uname) == "Linux" ] ; then ps -axww -o pid=,comm=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa,args= ; elif [ $(uname) == "Darwin" ] ; then ps -axww -o pid=,comm=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa,args= -c; fi'"

[ganibc]

Hi,

I run it and it returned
$(uname) was unexpected at this time.

[WardenGnaw]

Did you run it with the outer quotes included?

[ganibc]

Yes, I copied from your posting.
I found out that the problem seems from the "&&".
If I change "&&" to ";" now it seems to work and it returned

Linux
      aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
    1 init                                              /init
    3 bash                                              -bash
   56 sshd                                              /usr/sbin/sshd
  311 bash                                              -bash
  450 init                                              /init
  451 bash                                              /bin/bash -c uname ; if [ $(uname) == "Linux" ]; then ps -axww -o pid=,comm=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa,args= ; elif [ $(uname) == "Darwin" ]; then ps -axww -o pid=,comm=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa,args= -c; fi
  455 ps                                                ps -axww -o pid=,comm=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa,args=

This is the command line (I changed "uname &&" to "uname ;"
"c:\windows\sysnative\bash.exe" "-c" "bash -c 'uname ; if [ $(uname) == "Linux" ] ; then ps -axww -o pid=,comm=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa,args= ; elif [ $(uname) == "Darwin" ] ; then ps -axww -o pid=,comm=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa,args= -c; fi'"

Is there anything I can do to fix this on vscode?

[WardenGnaw]

Does uname && if [ $(uname) == "Linux" ] ; then ps -axww -o pid=,comm=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa,args= ; elif [ $(uname) == "Darwin" ] ; then ps -axww -o pid=,comm=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa,args= -c; fi not work in your WSL?

Also which Linux distro are you using for WSL?

[ganibc]

It works on my WSL.
I'm using ubuntu from the windows store.

[ganibc]

I see that the command line have extra 'bash -c'.
I remove that and now it works

"c:\windows\sysnative\bash.exe" "-c" "uname && if [ $(uname) == "Linux" ] ; then ps -axww -o pid=,comm=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa,args= ; elif [ $(uname) == "Darwin" ] ; then ps -axww -o pid=,comm=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa,args= -c; fi"

This is the one from your post (and I remove the "bash -c" part)
"c:\windows\sysnative\bash.exe" "-c" "_bash -c_ 'uname && if [ $(uname) == "Linux" ] ; then ps -axww -o pid=,comm=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa,args= ; elif [ $(uname) == "Darwin" ] ; then ps -axww -o pid=,comm=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa,args= -c; fi'"

Edit: And I confirmed yours is the same with the one from output window in vscode

[WardenGnaw]

Oh good catch. I completely missed that. Looks like our documentation is incorrect.

Here is the example configuration we provide if you click on the Add Configuration... on the bottom right in the launch.json file.

{
            "name": "(gdb) Bash on Windows Attach",
            "type": "cppdbg",
            "request": "attach",
            "program": "${workspaceFolder}/a.out",
            "processId": "${command:pickRemoteProcess}",
            "pipeTransport": {
                "debuggerPath": "/usr/bin/gdb",
                "pipeProgram": "C:\\Windows\\sysnative\\bash.exe",
                "pipeArgs": ["-c"],
                "pipeCwd": ""
            },
            "setupCommands": [
                {
                    "description": "Enable pretty-printing for gdb",
                    "text": "-enable-pretty-printing",
                    "ignoreFailures": true
                }
            ]
        }

[ganibc]

Hi,

Sorry I don't quite understand your reply mean.
Which one that I should add/remove from docs?
Looks the same to me except the pipeArgs part. Do I just need to remove args?

[WardenGnaw]

You want to change "processId": "${command:pickRemoteProcess}", to
"processId": "${command:pickProcess}",. That should fix the attach.

edit: the statement above was incorrect

I'll investigate why pickRemoteProcess does not work for WSL.

[ganibc]

I followed your suggestion.
The error is gone, but doesn't seems to be working.

I can see the process selection dialog and I can select the process. But that was it.

There's busy indicator between "variables" window and the launch selection drop down and it stays busy. I waited for around 5 minutes but it doesn't debug.

Edit: GDB is started (saw it in taskmanager) and it stopped if I closed the vscode (indicate it's owned by vscode)

[WardenGnaw]

@ganibc I did some further investigation and clarified which processPicker we should be using.
You should be using ${command:pickRemoteProcess}. However this scenario is broken due to bash.exe hanging.

This issue is with WSL in general. Here is their issue: https://github.com/Microsoft/WSL/issues/2680

The reason why ${command:pickProcess} is incorrect is because you will be given the windows process id instead of the linux process id. Which will cause gdb attach hang/fail.

[WSLUser]

The referenced issue is requesting back-ports of certain bugs/enhancements to 16299. Since there are no open bash.exe hangs on the WSL issue tracker, this might be new issue (and a regression). Considering how close the Spring Creator's Update is to releasing, I will wait to upgrade, then see if I can repro this issue. If it does repro, then we'll know for sure it's a regression that can be filed with WSL (unless another catch is needed with the docs like shown above).

In the meantime, you could always try using Debian to repro the error. Ubuntu has older packages so it wouldn't hurt to see if a more up to date gdb and friends on an even more stable platform.

you will be given the windows process id instead of the linux process id

I can think of a couple ways to address this. One I'm not completely sure about (unable to test) and the other is most likely to work.

Using the latest Insiders (or waiting for Spring Creator's Update):

Follow the WSL blog instructions for adding your Windows environmental variables to your Linux environmental variables. Specifically this from the blog may be relevant:

Debugging from VSCode will produce a Windows executable that you can also run.

Second method: Install choice of X server for Windows, usually use VcxSrv. Install VSCode on your Linux distro following VSCode procedures for installing on Linux. Follow normal debug procedures like you would on Real Linux. To ensure better interop on Windows side, recommend enabling -o metadata and fstab in wsl.conf per this. This will auto-mount your drives with the Linux metadata attributes extended when you open a WSL instance. Also recommend enabling case sensitivity on a per-directory basis. See this blog.

Keep in mind these may not be "fixes" per se but workarounds to avoid the issue.

[WardenGnaw]

This issue has been fixed in Version 1803.

https://support.microsoft.com/en-us/help/4028685/windows-10-get-the-update