Vscode-remote-release: GDB debugging session never starts

[rkeithhill]

Issue Type: Bug

1. Configure debug session to launch GDB pointing to workspace folder with gcc compiler version of binary.
2. Put breakpoint in a source file
3. Start debugging session.

Expected:
Debug session starts up, connects to gdb server and my breakpoint is hit.

Actual:
Debug session just spins and never starts.

I'm using:

      "type": "cppdbg",
      "request": "launch",

Do I need to be on the insiders version of the MS C++ extension?

Extension version: 0.32.0
VS Code version: Code - Insiders 1.34.0-insider (473af338e1bd9ad4d9853933da1cd9d5d9e07dc9, 2019-05-01T00:22:05.899Z)
OS version: Windows_NT x64 10.0.17763
Remote OS version: Linux x64 4.4.0-17763-Microsoft

System Info

|Item|Value|
|---|---|
|CPUs|Intel(R) Xeon(R) W-2123 CPU @ 3.60GHz (8 x 3600)|
|GPU Status|2d_canvas: enabled
checker_imaging: disabled_off
flash_3d: enabled
flash_stage3d: enabled
flash_stage3d_baseline: enabled
gpu_compositing: enabled
multiple_raster_threads: enabled_on
native_gpu_memory_buffers: disabled_software
rasterization: enabled
surface_synchronization: enabled_on
video_decode: enabled
webgl: enabled
webgl2: enabled|
|Load (avg)|undefined|
|Memory (System)|63.73GB (30.98GB free)|
|Process Argv||
|Screen Reader|no|
|VM|0%|

|Item|Value|
|---|---|
|Remote|WSL|
|OS|Linux x64 4.4.0-17763-Microsoft|
|CPUs|Intel(R) Xeon(R) W-2123 CPU @ 3.60GHz (8 x 3600)|
|Memory (System)|63.73GB (30.98GB free)|
|VM|0%|

[egamma]

@rkeithhill

Do I need to be on the insiders version of the MS C++ extension?

No this should not be required.

Can you share your setup so that we can try to reproduce the problem.

[wolfired]

try externalConsole=false in launch.json

[renkun-ken]

Same problem here. @wolfired's suggestion works for me perfectly!

[egamma]

//fyi @weinand

[weinand]

The C++ extension (cpptools) needs to improve its error handling/reporting. See https://github.com/microsoft/vscode/issues/67296.

[rkeithhill]

OK, the externalConsole=false works for launch but there is no such setting for attach. And attach doesn't work for me.

[weinand]

@rkeithhill since "attach" does not launch the target but just "attaches" to it, I don't understand how an "external terminal" can be involved here?

[PHubaut]

Same problem here but @wolfired's trick does not work for me.
Actually, I noticed that with "externalConsole": true, an xterm was opened which I could only see after starting VcXsrv server (and gnome interface) - this being said, the gdb session then works just fine (but it is annoying to have to start X11). With "externalConsole": false, nothing happens, debug sessions keep spinning waiting for something WSL side. My preference, though, would indeed be working with integrated console.

Version: 1.35.0-insider (user setup)
Commit: a5536b8f5a16a10d859f3dec1e59701671bf069e
Date: 2019-05-20T05:17:36.269Z
Electron: 3.1.8
Chrome: 66.0.3359.181
Node.js: 10.2.0
V8: 6.6.346.32
OS: Windows_NT x64 10.0.18362
Remote OS: WSL Linux 4.4.0-18362-Microsoft x86_64 (Ubuntu 18.04.2 LTS)
C/C++ Extension Version 0.23.1: May 13, 2019; WSL-installed
Remote WSL Extension Version 0.36.0

[rkeithhill]

I don't understand how an "external terminal" can be involved here?

I just meant that there isn't a workaround like that for the attach case.

[weinand]

@rkeithhill in the "attach" case the user is responsible for launching the debug target. So he can freely choose what terminal to use (and VS Code does not open a terminal automatically). So I do not understand why a workaround would be necessary at all.

[rkeithhill]

It's not about the terminal. It's about the fact that I haven't been able to attach to a process using (gdb) Attach via WSL Debug. I've started a Remote-WSL New Window session. Opened the workspace with my C++ code in it. This code is loaded by a .NET assembly that is in turn loaded by a PowerShell module into PowerShell. I configure the gdb attach "program" field to the path to pwsh - /opt/microsoft/powershell/6/pwsh. Although, why gdb needs the exe path for an "attach" scenario seems a bit odd to me.

I start the attach session, I enter the pid for the pwsh process and then I get this error in the "cppdbg: pwsh" terminal window:

[weinand]

@pieandcakes when "attaching" gdb to an already running process (an "attach" instead of a "launch" debug config), do you run gdb via DAP's runInTerminal request with a kind parameter external?

If yes, this would have the same problem as the "launch" case: if no external terminal is available or properly configured, the attach will fail.

Would it be possible to run gdb without a terminal, e.g. by forking gdb as a process and talking to it via stdin/stdout?

[pieandcakes]

@weinand we support the kind parameter today. I'll take a look at our attach scenario soon to see if we can work around this. As I understand it, you are asking us to not use runInTerminal when attaching. I'm pretty sure we don't do it today but I'll confirm.

[weinand]

@pieandcakes could you please take over this issue for investigation?
If there is anything VS Code (remote) needs top do, please let us know.

[WardenGnaw]

@rkeithhill A workaround for getting attach to work in WSL to run echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope

@weinand This scenario is where we know ptrace_scope is not set or non-zero, so we send the following prompt: Superuser access is required to attach to a process. Attaching as superuser can potentially harm your computer. Do you want to continue? [y/N] however, the debugger is stuck on waiting for a runInTerminal response and no output is given to the user in the integrated terminal.