Debug inside WSL

[MathiasMagnus]

Problem

Since it is now possible to launch VS Code from within WSL starting from Insider build 17063, I wanted to try side-by-side debugging, but for some reason VS Code cannot debug inside WSL. When I start to debug a Hello World application, this is what shows inside the debug output pane:

=thread-group-added,id="i1"
GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
=cmd-param-changed,param="pagination",value="off"
ERROR: Unable to start debugging. Unexpected GDB output from command "-exec-run". During startup program exited normally.
The program '/mnt/c/Users/nagy-/Source/MinimalCpp14/.vscode/build/Debug/MinimalCpp14' has exited with code 0 (0x00000000).

Am I doing something wrong?

[pieandcakes]

Can you share your launch.json? Are you setting this up exactly like debugging locally on Linux?

You can also get more information from what gdb is returning by enabling logging "logging": { "engineLogging": true } and seeing what -exec-run is returning unexpectedly

[MathiasMagnus]

This is the debug console output after logging being enabled: (omitting previous messages)

1: (975) <-1010-exec-run
1: (978) ->=thread-group-started,id="i1",pid="975"
1: (978) ->=thread-created,id="1",group-id="i1"
1: (978) ->=thread-group-exited,id="i1"
1: (979) ->1010^error,msg="During startup program exited normally."
1: (979) ->(gdb)
1: (983) <-1011-thread-info 1
1: (983) ->1011^done,threads=[]
1: (983) ->(gdb)
1: (986) 1010: elapsed time 11
1: (991) 1011: elapsed time 7
1: (994) <--gdb-exit
1: (994) ->^exit
ERROR: Unable to start debugging. Unexpected GDB output from command "-exec-run". During startup program exited normally.
The program '/mnt/c/Users/nagy-/Source/MinimalCpp14/.vscode/build/Debug/MinimalCpp14' has exited with code 0 (0x00000000)

The example is no black magic.

Main.cpp

#include <iostream>
#include <functional>

int main()
{
    [console = std::ref(std::cout)]()
    {
        console.get() <<
            "Hello, generic lambda capture!" <<
            std::endl;
    }();

    return 0;
}

CMakeLists.txt

cmake_minimum_required(VERSION 3.5)

project(MinimalCpp14 LANGUAGES CXX)

add_executable(${PROJECT_NAME} Main.cpp)

set_target_properties(${PROJECT_NAME} PROPERTIES
                      CXX_STANDARD 14
                      CXX_STANDARD_REQUIRED ON
                      CXX_EXTENSIONS OFF)

lanch.json

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "MinimalCpp14",
            "type": "cppdbg",
            "request": "launch",
            "program": "${workspaceFolder}/.vscode/build/Debug/MinimalCpp14",
            "args": [],
            "stopAtEntry": false,
            "cwd": "${workspaceFolder}",
            "environment": [],
            "externalConsole": true,
            "MIMode": "gdb",
            "setupCommands": [
                {
                    "description": "Enable pretty-printing for gdb",
                    "text": "-enable-pretty-printing",
                    "ignoreFailures": true
                }
            ],
            "logging": {

                "engineLogging": true,
                "trace": false
            }
        }
    ]
}

settings.json

{
    "cmake.buildDirectory": "${workspaceRoot}/.vscode/build/${buildType}"
}

As far as I know this should be working. The source files are located on my NTFS drive, as the /mnt/c/... path of the executable suggests.

[MathiasMagnus]

Top

• Ubuntu Server 16.04
• VS Code 1.19.1
• CMake Tools 0.11.0-beta4
• C/C++ 0.14.5
• GCC 7.2.0

Bottom

• Ubuntu (WSL) 16.04
• VS Code 1.19.1
• CMake Tools 0.11.0-beta4
• C/C++ 0.14.5
• GCC 7.2.0

It cannot be anymore identical I believe. The only difference is that one is a native Ubuntu connected to via SSH and the other is running from WSL without SSH.

Host

• Windows 10 (Insider build 17063)
• VcXsrv 1.19.3.1

[MathiasMagnus]

@bitcrazed As a sidenote, while I was trying to put together the environment of VS Code in WSL, I got about 3 Green Screen of Deaths in roughly 20-30 minutes of experimenting. KERNEL_SECURITY_CHECK_FAILURE

Should one expect WSL folks to dig into crash dumps created while using VS Code in WSL? Is there any group within MS that might potentially provide a repro to catch in a debugger?

Sidenote of sidenote: still waiting for the GPGPU in WSL blog post, hopefully mentioning Khronos tech as well, not just propriatary CUDA.

[pieandcakes]

@MathiasMagnus I don't know if VSCode has done any testing to support itself inside WSL or if they have been working with the WSL team to resolve this.

Your example above looks like it doesn't have symbols so it isn't stopping. Can you make sure you are compiling with Debug symbols (compiler flag -g) and try again?

We are getting a gdb error when we try and run the debuggee of:

1: (979) ->1010^error,msg="During startup program exited normally."

[bitcrazed]

@MathiasMagnus HIGHLY unlikely that these security checks were due to WSL, though if you can repro after update to most recent build , please file an issue on the WSL repo with as much info and repro steps as possible.

As we've stated previously, we're looking at GPU access, but it's a really tough nut to crack that will take engineering from Microsoft and partners, so please bear with us for now.

[bitcrazed]

Hey @Tyriar - any chance you could take a look at this issue please? :)

[Tyriar]

I was under the impression that debugging simply does not work under WSL/git bash currently microsoft/vscode#30592

[pieandcakes]

@Tyriar Is that true if I install VSCode for Ubuntu on WSL also? I'm just asking but I haven't tried it yet as I am not running the insiders Windows build

[MathiasMagnus]

I don't think it's related to the issue you linked. Ubuntu inside WSL (the native VS Code I'm talking about) should have no knowledge about being inside WSL, and hence the path formats should not cause an issue on any level. Am I missing something?

[Tyriar]

@pieandcakes we don't support running the Linux binaries on WSL.

[MathiasMagnus]

@Tyriar Not (officially) supporting is one thing (means that the issue can be closed at will) and not wanting to support is another. The prior means users looking for it might have to wait arbitrarily long, and the latter means waiting for forever.

VS Code under WSL was one of the most trending issues, so there must be value to it.

[Tyriar]

@MathiasMagnus I believe the team behind WSL does not recommend embracing launching Linux GUI apps, @bitcrazed can correct me if I'm wrong (this may be old information?). Where we (the vscode team) do want to improve support eventually is in the launching of WSL-based tooling from within the Windows GUI.