[Linux] Cannot launch gdb debugging session (with externalConsole set to true)

[UniverseIsProprietary2]

Version: 1.30.1
Commit: dea8705087adb1b5e5ae1d9123278e178656186a
Date: 2018-12-18T18:07:32.870Z
Electron: 2.0.12
Chrome: 61.0.3163.100
Node.js: 8.9.3
V8: 6.1.534.41
OS: Linux x64 4.19.13-1-lts (Arch Linux)

C/C++ Extension Version: 0.20.1 (also tried the latest insiders version)

launch.json configuration:

{
    // 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": "(gdb) Launch",
            "type": "cppdbg",
            "request": "launch",
            "program": "${workspaceFolder}/a.out",
            "args": [],
            "stopAtEntry": false,
            "cwd": "${workspaceFolder}",
            "environment": [],
            "externalConsole": true,
            "MIMode": "gdb",
            "setupCommands": [
                {
                    "description": "Enable pretty-printing for gdb",
                    "text": "-enable-pretty-printing",
                    "ignoreFailures": true
                }
            ]
            
        }
    ]
}

Basic hello world code:

#include <stdio.h>
int main()
{
   printf("Hello, World!");
   return 0;
}

Compiled with:

gcc main.c -g

Upon launching the debugging, the debugger simply hangs and does nothing:

/home/xxx/.vscode/extensions/ms-vscode.cpptools-0.21.0-insiders2/debugAdapters/mono.linux-x86_64 --config /home/xxx/.vscode/extensions/ms-vscode.cpptools-0.21.0-insiders2/debugAdapters/framework/config.linux /home/xxx/.vscode/extensions/ms-vscode.cpptools-0.21.0-insiders2/debugAdapters/bin/OpenDebugAD7.exe

Launching OpenDebugAD7 from extension's directory outputs:

waiting for v8 protocol on stdin/stdout

Which indicates, that it's waiting for the connection, but does not receives the latter.

[UniverseIsProprietary2]

Setting "externalConsole": false in launch.json solves the problem, but why external console isn't launched?

The resulting launch.json:

{
    // 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": "(gdb) Launch",
            "type": "cppdbg",
            "request": "launch",
            "program": "${workspaceFolder}/a.out",
            "args": [],
            "stopAtEntry": false,
            "cwd": "${workspaceFolder}",
            "environment": [],
            "externalConsole": false,
            "MIMode": "gdb",
            "setupCommands": [
                {
                    "description": "Enable pretty-printing for gdb",
                    "text": "-enable-pretty-printing",
                    "ignoreFailures": true
                }
            ]
            
        }
    ]
}

Also, the solution @microsoft/vscode#6107 (comment) does not work.

[UniverseIsProprietary2]

I've installed Xterm on Arch Linux and now everything works fine (it's not there by default as in Ubuntu distros, for example). On Ubuntu with the latest insider's build the terminal fires up and everything works fine, on Arch, however, it does not, unless Xterm is installed and then upon launching debugging with "externalConsole": true, Xterm is launched instead of default DE's terminal.

[UniverseIsProprietary2]

It turns out (according to this comment: microsoft/MIEngine#752 (comment)) Xterm was set as a default terminal in VSCode settings, I've changed it to gnome-terminal and everything works fine now. I guess, it would be good to mention that somewhere in documentation as not everyone has Xterm installed.

[pieandcakes]

@UniverseIsProprietary2 We use the VS Code Debug Protocol's RunInTerminal command now to launch external terminals on Linux. What that means is that the setting is now set in VS Code, which I think they default to xTerm.

You can change the setting in VS Code's File -> Preferences -> Settings by searching for Terminal.External. Here's a screenshot of the default setting:

[pieandcakes]

Pinning this so others running into it will know how to get around it.

[therealkenc]

which I think they default to xTerm.

FWIW for me anyway, the default started off life as x-terminal-emulator (not xterm). I'm on Ubuntu (aka Debian derrived). I found this code here which seems to try heuristics (existence /etc/debian_version and poking around environment variables) to try to guess. So it isn't straightforward. [I can't tell you if that's the correct source hit. It was a WAG code search and I'm not a VS code internals expert.]

I hope this can be documented better somewhere beyong pinning a rando thread on github, because it is nonobvious. That linked comment nonchalantly offered "This will allow you to specify the terminal client through the VS Code settings" under the gross assumption anyone would have the faintest idea how to go about doing that.

[pieandcakes]

@therealkenc I've pinned it in the hopes that as the title suggests, people who run into this will look at the pinned issue and be able to quickly figure out if they are running into the same issue. There's this article from 2016 but I can't find an official document from the VS Code team about the setting.

TBH I didn't know about the setting either until we started talking about this issue and I glanced over another issue that had a comment about it.

[thomasreiser]

All these proposals are not working on my Arch machine.

If have set the external terminal to gnome-terminal, xterm and x-terminal-emulator - none of them worked.
I have also set externalConsole to true and false.

I always get the same error:
Stopping due to fatal error: NullReferenceException: Object reference not set to an instance of an object

Strange to have a IDE which is not able to debug out of the box..

My version of VS Code:

Version: 1.32.0-insider
Commit: 393b48d4a5de85b6fa1d2ad0a59588d6715e12ea
Date: 2019-02-25T06:13:04.879Z
Electron: 3.1.3
Chrome: 66.0.3359.181
Node.js: 10.2.0
V8: 6.6.346.32
OS: Linux x64 4.20.11-arch2-1-ARCH

Version of C/C++ tools:

0.22.0-insiders

Am I doing something wrong?

[sean-mcmanus]

@pieandcakes Can we unpin this now?

[therealkenc]

Dunno what merits an issue worthy of being pinned (I have no horse in race), but until Microsoft/vscode#67296 is addressed folks are going to keep seeing the vscode-cpptools debugger silently failing to launch on folks' various quirky rigs like Arch or Gentoo or WSL or whatever. These are all possible to get right, natch; but they are also fairly easy to get wrong.

Maybe absent being pinned the (currently) silent-fail-by-design behavior could be documented somewhere if it isn't already. And now that the Remote - SSH plugin dropped, there is a good chance folks are going to see it more often.

[pieandcakes]

@sean-mcmanus I agree with what @therealkenc says. VSCode still needs to generate an error so we don't hang/fail silently.

[dunderX]

what's up with that? still doesn't work for me

#3698

[Airbus5717]

Me too