Not able to debug in WSL with Remote - WSL plugin

[HymanZHAN]

Which OS: Windows 10
Which VSCode version: 1.34.0-insiders
Which extension version: 1.2.3
Which adapter type: classic
Which LLDB version: 6.0.0

What is the problem and how did you get there:

• Problem:
  Not able to debug a Rust program in WSL session with the Remote - WSL plugin

• How to reproduce:

  • Create a new project by cargo new guessing_game --bin
  • In src/main.rs type in:

  fn main() {
      let name = "my_name";
      println!("Hello, {}!", name);
  }

  • Add a break point at line println!("Hello, {}!", name);
  • Debug with the following launch.json:

{
  "version": "0.2.0",
  "configurations": [
    {
      "type": "lldb",
      "request": "launch",
      "name": "Debug executable 'guessing_game'",
      "cargo": {
        "args": ["build", "--bin=guessing_game", "--package=guessing_game"],
        "filter": {
          "name": "guessing_game",
          "kind": "bin"
        }
      },
      "args": [],
      "cwd": "${workspaceFolder}"
    },
    {
      "type": "lldb",
      "request": "launch",
      "name": "Debug unit tests in executable 'guessing_game'",
      "cargo": {
        "args": [
          "test",
          "--no-run",
          "--bin=guessing_game",
          "--package=guessing_game"
        ],
        "filter": {
          "name": "guessing_game",
          "kind": "bin"
        }
      },
      "args": [],
      "cwd": "${workspaceFolder}"
    }
  ]
}

• Output

Running `cargo build --bin=guessing_game --package=guessing_game --message-format=json`...
    Finished dev [unoptimized + debuginfo] target(s) in 0.02s
Raw artifacts:
{ fileName:
   '/mnt/c/Users/zhanx/Development/Projects/guessing_game/target/debug/guessing_game',
  name: 'guessing_game',
  kind: 'bin' }
Filtered artifacts: 
{ fileName:
   '/mnt/c/Users/zhanx/Development/Projects/guessing_game/target/debug/guessing_game',
  name: 'guessing_game',
  kind: 'bin' }
configuration: { type: 'lldb',
  request: 'launch',
  name: 'Debug executable \'guessing_game\'',
  args: [],
  cwd: '${workspaceFolder}',
  program:
   '/mnt/c/Users/zhanx/Development/Projects/guessing_game/target/debug/guessing_game',
  sourceLanguages: [ 'rust' ] }
(lldb) command script import '/home/xzhan/.vscode-remote/extensions/vadimcn.vscode-lldb-1.2.3/adapter'
bind: Invalid command `enable-meta-key'.
(lldb) script adapter.run_tcp_session(0, 'eyJzb3VyY2VMYW5ndWFnZXMiOlsicnVzdCJdfQ==')
Listening on port 51353

• Debug windows output:

Display settings: variable format=auto, show disassembly=auto, numeric pointer values=off, container summaries=on.
Launching /mnt/c/Users/zhanx/Development/Projects/guessing_game/target/debug/guessing_game 
Module loaded: /mnt/c/Users/zhanx/Development/Projects/guessing_game/target/debug/guessing_game. Symbols loaded.
Process exited with code -1.

• Others

The code-lldb plugin did not recognize the Cargo.toml file as on Linux and therefore, was not able to generate the launch.json based on that file. The above launch configuration was copied from an identical Rust project on Linux and used in this project.

Update: The code-lldb plugin was able to recognize the Cargo.toml file after all. Probably due to a reboot.

[HymanZHAN]

Maybe similar to this issue #141

[vadimcn]

I'm not sure debugging in WSL works at all - last time I checked, it did not implement enough of strace syscall for lldb to function. I would recommend testing this using command line lldb first.

In any case, debugging a WSL process with Win32 debugger will not work. You need to treat WSL debugging as a remote target - start a Linux version of lldb-server, then connect to it as if it were on a remote machine.

Actually, these days it might be easier to use VSCode Remote Development capabilities.

[HymanZHAN]

That's what I am trying to use here. I used the Remote-WSL plugin and was able to "remotely" debug C++ programs on WSL with gdb. So I guess you are right, as I tested with the lldb command line it shows the below messages:

xzhan@Xucong-Desktop:~/Development/Projects/guessing_game$ lldb ./target/debug/guessing_game
(lldb) target create "./target/debug/guessing_game"
Current executable set to './target/debug/guessing_game' (x86_64).
(lldb) breakpoint list 
No breakpoints currently set.
(lldb) breakpoint set --file main.rs --line 3
Breakpoint 1: 2 locations.
(lldb) breakpoint list
Current breakpoints:
1: file = 'main.rs', line = 3, exact_match = 0, locations = 2
  1.1: where = guessing_game`guessing_game::main::hbfab0a0a1840e223 + 28 at main.rs:3, address = guessing_game[0x0000000000006a9c], unresolved, hit count = 0 
  1.2: where = guessing_game`guessing_game::main::hbfab0a0a1840e223 + 51 at main.rs:3, address = guessing_game[0x0000000000006ab3], unresolved, hit count = 0 

(lldb) run
Process 6971 launched: './target/debug/guessing_game' (x86_64)
Process 6971 exited with status = -1 (0xffffffff) lost connection

[ghost]

I have the same problem using VSCode remote WSL, but it seem like a python problem, and the debug session stuck at starting the app.

Here is the log from the output with verbose turn on :
trace.log

The log from debug console:
Launching: /mnt/d/Workspace/Code/SourceCode/Rust/guessing_game/target/debug/guessing_game

My launch option:

{
      "type": "lldb",
      "request": "launch",
      "name": "Debug executable 'guessing_game'",
      "cargo": {
        "args": [
          "build",
          "--bin=guessing_game",
          "--package=guessing_game"
        ],
        "filter": {
          "name": "guessing_game",
          "kind": "bin"
        }
      },
      "args": [],
      "cwd": "${workspaceFolder}"
}

My python's version is 2.7.16

[witzatom]

WSL 2 fixes the issue probably. Debugging via lldb works for me out of the box in WSL 2.

[HymanZHAN]

@tommassino That's good to know but no much surprise. WSL 2 has a real Linux kernel so I would be surprised if it does not work.

[AlexanderAllen]

Currently not being able to use in WSL 2 Alpine.

But libgcc is installed

Provided by package
https://pkgs.alpinelinux.org/contents?branch=edge&name=libgcc&arch=x86_64&repo=main

GCC is present via build-base Alpine meta-package:

LLDB also works natively:

Running on WSL 2:

[robertwt7]

It goes the same for me.. was working fine in mac

In WSL 1, haven't upgraded to WSL 2 from my end. It just says its launching lldb and that's it

[vadimcn]

CodeLLDB is built for glibc-based Linux'es. I might work on Alpine if you install glibc, but I've never tried this.

[pojntfx]

@vadimcn Just tried this. Fails with the following:

/tmp/vscode-unpacked/vadimcn.vscode-lldb.vsix/extension/adapter/codelldb: error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory
Error: The debugger exited without completing startup handshake.