Vscode-cpptools: Unable to start debugging. Failed to initialize debugger terminal.

[Tomaszal]

I am trying to debug a simple "Hello world!" application with VSCode on a 64 bit Arch Linux machine. Compiling is done without a problem, but when I go to debug it, about 10 seconds pass and it spits out this error: Unable to start debugging. Failed to initialize debugger terminal. I am using the default GDB/LLDB environment for launch.json.

Things I've tried:

• Changing "_externalConsole_" to false.
• Changing "_terminal.external.linuxExec_" to a different shell.
• Changing "_terminal.integrated.shell.linux_" to a different shell.

[pieandcakes]

@tomaszal Do you have xterm or gnometerminal installed? We currently only support those two options. There is a backlog item to add other options in the future.

[Tomaszal]

@pieandcakes I do have xterm installed and I've just tested it with gnome-terminal. Neither of them work and both return the same error. What's stranger is that even when I set "_externalConsole_" to false, which in my understanding should use the internal shell with bash, it returns the same error.

[pieandcakes]

@Tomaszal the terminal options is not part of our extension and it isn't an option that we support at this time. Can you post your launch.json?

[Tomaszal]

@pieandcakes it's just the default generated one: http://pastebin.com/TkFWbupt

[pieandcakes]

@Tomaszal Yea, that is strange. If you enable logging in the launch.json can you send me what it says? I think you're going to want to set trace and traceResponse to true.

[pieandcakes]

@Tomaszal One of our tests machine is running Arch Linux x64 (4.6.4) with XTerm(325) and gnome-terminal 3.20.2 installed and it is running on there with gdb version 7.11.1.

[Tomaszal]

Here's the log:

R: {"success":false,"message":"Unable to start debugging. Failed to initialize debugger terminal.","request_seq":2,"command":"launch","body":{"error":{"id":1104,"format":"Unable to start debugging. Failed to initialize debugger terminal.","variables":null}},"running":false,"refs":null,"seq":0,"type":"response"}
C disconnect: {"restart":false}
R: {"success":true,"message":null,"request_seq":3,"command":"disconnect","body":null,"running":false,"refs":null,"seq":0,"type":"response"}

I'm currently on Arch Linux version 4.8.11, Xterm 327, gnome-terminal 3.22.1 and GDB 7.12. What's more strange is that CodeBlocks and Atom work fine on this machine.

[Tomaszal]

I've recently reinstalled Arch Linux and decided to try running this again and it is now working correctly.

Now that I look back on it though I think I know what the problem was. I had both KDE and GNOME installed so I could experiment with both of them (I'm a new Linux user). I only used GNOME a few times but gnome-terminal got installed with it. I think the issue was that the debugger gave priority to gnome-terminal which couldn't run properly under my KDE setup so it just failed. Currently I have just XTerm installed and it runs just fine.

On another note I think that adding support for integrated terminal would be a nice option.

[pieandcakes]

@Tomaszal Thanks for the update. The integrated terminal is something that we have on our radar for a future release. We do prefer gnome-terminal and fall back to xterm when it doesn't exist.

[knedlsepp]

I'm having the same problem and can't figure out how to make it work. I got xterm and gdb on my $PATH.

[brandon-kohn]

Same issue here.

[pieandcakes]

@knedlsepp @brandon-kohn Do either of you have gnome-terminal also installed? We use gnome-terminal first and then fallback to XTerm. You can try and change "externalConsole": false in the launch.json and see if it works without the console.

[FieryCod]

I got a Xterm as well as gnome-terminal installed. Saddly it does not work, I receive all messages which OP mentioned.

EDIT: One of the possible solution to overcome that bug is to change gdb to lldb:

"linux": {
"MIMode": "lldb",
"setupCommands": [
{
"description": "Enable pretty-printing for gdb",
"text": "-enable-pretty-printing",
"ignoreFailures": true
} ]
}

Using ArchLinux.

[xshadowlegendx]

Hello, I'm having same issue right now of cannot initialize the debugger, and here is my launch.json
{
"version": "0.2.0",
"configurations": [
{
"name": "C++ Launch",
"type": "cppdbg",
"request": "launch",
"program": "${workspaceRoot}/a.out",
"args": [],
"stopAtEntry": false,
"cwd": "${workspaceRoot}/",
"logging": { "trace": true, "traceResponse": true, "engineLogging": true },
"environment": [],
"externalConsole": false,
"linux": {
"MIMode": "gdb",
"setupCommands": [
{
"description": "Enable pretty-printing for gdb",
"text": "-enable-pretty-printing",
"ignoreFailures": true
}
]
},
"osx": {
"MIMode": "lldb"
},
"windows": {
"MIMode": "gdb",
"setupCommands": [
{
"description": "Enable pretty-printing for gdb",
"text": "-enable-pretty-printing",
"ignoreFailures": true
}
]
}
},
{
"name": "C++ Attach",
"type": "cppdbg",
"request": "attach",
"program": "${workspaceRoot}/a.out",
"processId": "${command:pickProcess}",
"linux": {
"MIMode": "gdb",
"setupCommands": [
{
"description": "Enable pretty-printing for gdb",
"text": "-enable-pretty-printing",
"ignoreFailures": true
}
]
},
"osx": {
"MIMode": "lldb"
},
"windows": {
"MIMode": "gdb",
"setupCommands": [
{
"description": "Enable pretty-printing for gdb",
"text": "-enable-pretty-printing",
"ignoreFailures": true
}
]
}
}
]
}

the debug error log:

1: (287) LaunchOptions 1: (300) LaunchOptions ExePath='/home/shadowlegend/Desktop/Project/C++/Accelerated C++(14)/exerices/a.out'
1: (300) LaunchOptions WorkingDirectory='/home/shadowlegend/Desktop/Project/C++/Accelerated C++(14)/exerices/'
1: (300) LaunchOptions ExeArguments=''
1: (300) LaunchOptions MIMode='gdb'
1: (300) LaunchOptions MIDebuggerPath=''
1: (300) LaunchOptions WaitDynamicLibLoad='false'
R: {"success":false,"message":"Unable to start debugging. Failed to initialize debugger terminal.","request_seq":2,"command":"launch","body":{"error":{"id":1104,"format":"Unable to start debugging. Failed to initialize debugger terminal.","variables":null}},"running":false,"refs":null,"seq":0,"type":"response"}
C disconnect: {"restart":false}
R: {"success":true,"message":null,"request_seq":3,"command":"disconnect","body":null,"running":false,"refs":null,"seq":0,"type":"response"}

my tasks.json

{
// See https://go.microsoft.com/fwlink/?LinkId=733558
// for the documentation about the tasks.json format
"version": "0.1.0",
"command": "g++",
"isShellCommand": true,
"args": ["-g", "--pipe", "--std=c++14", "${file}", "-lm"],
"showOutput": "always"
}

I have both xTerms and gnome-terminal, and i also have fish shell, but i tried removing it and still had the same error, i try reading some issue but still could not find the solution, im using Arch Linux.

[FieryCod]

Try to change mimode to lldb as I wrote above

[xshadowlegendx]

Ok, I will try it right away and let u know after

[xshadowlegendx]

Hello, I've changed it to lldb, but i do not know if it works correct, when i run my program requiring to input my name, then it draw the frame around it ( exercise from Accelerated C++ book ), after i input my name, the debugger just hang and output the message:

"Unable to perform this action because the process is running".

When i close the debugger this message appear:

"Execute debugger commands using "-exec ", for example "-exec info registers" will list registers in use (when GDB is the debugger)
The program '/home/shadowlegend/Desktop/Project/C++/Accelerated C++(14)/exerices/a.out' has exited with code 0 (0x00000000)."

I believed the program exited with code 0 mean no error ? but why it isnt running the rest of the code, which after i input my name, it should draw the frame around it.
I only made changes to the MIMode from gdb to lldb, the tasks.json and settings.json did not made any new changes.

[sean-mcmanus]

What happens when you run your program without the debugger attached? Did you set a breakpoint? What is the debugger action you are trying to do? Is the debugger running or pausing your main thread? Do you see anything in the call stack section?

[xshadowlegendx]

Hello, I've tried to set the breakpoint but it is still the same, since it is the first time i use the visual studio code, i still have not got used to properly run the program without debugger, which i run the program myself from terminal. I'm trying to test the debugging to see if it works so that i could work on my coding, the debugger first running but then it just pausing a the the input part.
Here is my code and the debugger console
[https://postimg.org/image/8butsmfvh/]

[hengck23]

i have the same problem as above.
My system is ubuntu 16.04. When is use gdb, the error is: "Unable to start debugging. Failed to initialize debugger terminal". gdb works well from my terminal without vs code.

Enable logging in the launch.jason gives:
"R: {"success":false,"message":"Unable to start debugging. Failed to initialize debugger terminal.","request_seq":2,"command":"launch",
"body":{"error":{"id":1104,"format":"Unable to start debugging. Failed to initialize debugger terminal.","variables":null}},
"running":false,"refs":null,"seq":0,"type":"response"}
C disconnect: {"restart":false}
R: {"success":true,"message":null,"request_seq":3,"command":"disconnect","body":null,"running":false,"refs":null,"seq":0,"type":"response"}
"

---

I can solve the issue by changing gdb to lldb. However, it would really like to use gdb. Anyone has any suggestion?

[pieandcakes]

@hengck23 we try and use gnone-terminal and fall back to xTerm for our debugger terminal. If those are not installed on your instance of Ubuntu, you get the below message. I don't know why switching to lldb would work and i'll take a look when I have time.

[ghost]

@pieandcakes Are there any plans to allow other terminal emulators? I have my current one (xfce4-terminal) configured exactly how I like it, and using a different one for VSCode debugging is very less than ideal.

[pieandcakes]

@DougTy With the number of terminal emulators out there and the amount of different flags for each one we would need to support, it isn't something we support today. That being said, we have an issue filed here, #515 that is tracking the request for other terminal apps. We also take community contributions so if you feel like it would be something you'd want to contribute, the code in question isin that issue also

[evilArsh]

@Tomaszal
i find out why it shows

Failed to initialize debugger terminal.

my OS version is ubuntu 16.04 LTS and i check the directory/usr/bin ,there are two files,one is the python file named gnome-terminal and another one is gnome-terminal.real ,the real file to lunch terminal is the second one (type gnome-terminal.real in a terminal to lunch a new terminal)—— gnome-terminal.real ,it means that you must use command
python /usr/bin/gnome-terminal to lunch the terminal.but this is a python file , i guess vscode just find the file gnome-terminal and do something.

root@vivjackPC:/usr/bin# mv ./gnome-terminal ./gnome-terminal.bak
root@vivjackPC:/usr/bin# mv ./gnome-terminal.real ./gnome-terminal

then vscode works

[Nagi5Yeq]

I am using ubuntu 16.04 and gdb to debug.I find that when my folder is named "pro32" or "pro-32",vscode can debug successfully.But when my folder is named "pro(32)" or "pro(" or "pro)",I have the same problem.So I think is the matter of name.

[pieandcakes]

@Yugata I think your issue is separate from the above comments about gnome-terminal and other terminal types

[hamzakilic]

my working folder like "ham-serv (copy)" and debugging was giving the same error. then I changed folder name "hamservtest" and worked fine. I think a problem can be some characters at path .

[puchodr]

I'm also having the same issue right now when trying to attach to a process. My Visual Studio Code version

Version 1.20.1
Commit f88bbf9137d24d36d968ea6b2911786bfe103002
Date 2018-02-13T15:31:21.019Z
Shell 1.7.9
Renderer 58.0.3029.110
Node 7.9.0
Architecture x64

Here is my launch.json:
{
// Use IntelliSense to learn about possible attributes.\n
// Hover to view descriptions of existing attributes.
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
{
"name": "Attach",
"type": "cppdbg",
"request": "attach",
"program": "~/builds/proj/bin/test",
"processId": "${command:pickProcess}",
"MIMode": "gdb",
"logging": {
"trace": true,
"traceResponse": true
}
}
]
}

Here is the output in the Debug Console with Logging enabled:
E output: {"category":"telemetry","output":"VS/Diagnostics/Debugger/Attach","data":{"VS.Diagnostics.Debugger.ImplementationName":"Microsoft.MIDebugEngine","VS.Diagnostics.Debugger.EngineVersion":"14.0.50106.1","VS.Diagnostics.Debugger.HostVersion":"1.0.40106.1","VS.Diagnostics.Debugger.AdapterId":"cppdbg","VS.Diagnostics.Debugger.Attach.Message":"Unable to start debugging. Failed to initialize debugger terminal.","VS.Diagnostics.Debugger.Attach.IsError":true},"type":"output"}
R: {"success":false,"message":"Unable to start debugging. Failed to initialize debugger terminal.","request_seq":2,"command":"attach","body":{"error":{"id":1104,"format":"Unable to start debugging. Failed to initialize debugger terminal.","variables":null}},"running":false,"refs":null,"seq":0,"type":"response"}
C disconnect: {"restart":false}
R: {"success":true,"message":null,"request_seq":3,"command":"disconnect","body":null,"running":false,"refs":null,"seq":0,"type":"response"}

I have both gnome-terminal and xterm installed, so I don't think that's the issue. I also tried to replace gdb with lldb which gives me a different error about the MiDebuggerPath. When I set the path lldb doesn't like the --interpreter argument. It doesn't recognize it. Thanks for the help.

[pieandcakes]

@puchodr which Linux distribution are you on? Have you tried reinstalling the extension? When using lldb, you need to target the lldb-mi executable.

[puchodr]

Linux distribution is:
LSB Version: :core-4.1-amd64:core-4.1-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-4.1-amd64:desktop-4.1-noarch:languages-4.1-amd64:languages-4.1-noarch:printing-4.1-amd64:printing-4.1-noarch
Distributor ID: RedHatEnterpriseWorkstation
Description: Red Hat Enterprise Linux Workstation release 7.2 (Maipo)
Release: 7.2
Codename: Maipo

So more specifically, this doesn't work when running as root. I just reinstalled the extension and was able to attach as a user not root. Unfortunately, we have a need to run as root so it would be ideal if we can figure out why this issue is specific to root. I also set the --user-data-dir argument to the directory of the user that installed the cpp extension and it still didn't work. The extension loaded correctly, but the console wouldn't launch.

[pieandcakes]

If you are attempting to attach to a process running as root with an instance of VS Code running as a user, we try and determine that you are running as root and then attempt to ask the user to elevate. The relevant code is here. If we detect that the app is running under root, then we try and prompt the user for credentials using pkexec and falling back to sudo.

If you are also trying to run VS Code as root and not able to attach, I would try and run it as the user and see if you get the elevation prompts. We tested this back on Ubuntu 14.04 so there might be some fixes needed.

[puchodr]

I'm running VS Code as root. The computer I'm moving to only has a root user and won't be having any non-root users. So I need to be able to debug as root while the process is running as root.

[pieandcakes]

I don't think we've tried that. I'll have to give it a shot to see what about it doesn't work. Can you open another issue on this? it isn't the same issue as this one.

Also, please provide a log with just "logging" : { "engineLogging": true } enabled to see if we can tell what we get back from gdb, if anything.

[puchodr]

1: (266) LaunchOptions 1: (279) LaunchOptions ExePath='~/builds/proj/bin/test'
1: (279) LaunchOptions ExeArguments=''
1: (279) LaunchOptions MIMode='gdb'
1: (279) LaunchOptions MIDebuggerPath=''
1: (279) LaunchOptions WaitDynamicLibLoad='false'
1: (279) LaunchOptions ProcessId='15527'
1: (279) LaunchOptions>
1: (279) LaunchOptions
1: (377) TempFile=/tmp/Microsoft-MIEngine-fifo-qd9jze0k.dvc
1: (377) TempFile=/tmp/Microsoft-MIEngine-fifo-qjn659bf.h5q
1: (377) TempFile=/tmp/Microsoft-MIEngine-fifo-5tb2e4ui.ai9

[pieandcakes]

@puchodr Ah, it looks like it can't find gdb. Can you add the path to your gdb by specifying "miDebuggerPath": "<Path to gdb>" in your launch.json?

[puchodr]

Only difference now is the debugger path. Same issue though
1: (227) LaunchOptions 1: (242) LaunchOptions ExePath='~/builds/proj/bin/test'
1: (243) LaunchOptions ExeArguments=''
1: (243) LaunchOptions MIMode='gdb'
1: (243) LaunchOptions MIDebuggerPath='/usr/bin/gdb'
1: (243) LaunchOptions WaitDynamicLibLoad='false'
1: (243) LaunchOptions ProcessId='15527'
1: (243) LaunchOptions>
1: (243) LaunchOptions
1: (319) TempFile=/tmp/Microsoft-MIEngine-fifo-4ynjzw8p.eok
1: (319) TempFile=/tmp/Microsoft-MIEngine-fifo-dz79ld2t.30u
1: (319) TempFile=/tmp/Microsoft-MIEngine-fifo-pch5xxuq.zgy

[pieandcakes]

From your elevated terminal window can you run /usr/bin/gdb --interpreter=mi and see if it starts? If it does, then it might be our launch command, which i'll need to find it.

[puchodr]

/usr/bin/gdb --interpreter=mi successfully launches gdb.

Btw, I really appreciate the help. You're going above and beyond. Thank you.

[puchodr]

So just for science I reconfigured things to run vscode as a non-root user. I'm currently getting "Unable to start debugging. Attaching to process 13550 with GDB failed because of insufficient privileges with error message 'ptrace: Operation not permitted.'." when trying to attach to a process running as root. The user does have sudoers permissions. Sorry if it's too much but here's the log with engineLogging, trace, and traceResponse.

1: (293) LaunchOptions 1: (306) LaunchOptions ExePath='~/builds/proj/bin/test'
1: (306) LaunchOptions ExeArguments=''
1: (306) LaunchOptions MIMode='gdb'
1: (306) LaunchOptions MIDebuggerPath=''
1: (306) LaunchOptions WaitDynamicLibLoad='false'
1: (306) LaunchOptions ProcessId='13550'
1: (306) LaunchOptions>
1: (306) LaunchOptions
1: (381) TempFile=/tmp/Microsoft-MIEngine-fifo-tresny0l.g8q
1: (381) TempFile=/tmp/Microsoft-MIEngine-fifo-1bs8pc5m.i9q
1: (381) TempFile=/tmp/Microsoft-MIEngine-fifo-m5zmejry.421
1: (524) ShellPid=15376
1: (586) DebuggerPid=15379
1: (598) ->=thread-group-added,id="i1"
1: (599) ->~"GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-80.el7\n"
1: (599) ->~"Copyright (C) 2013 Free Software Foundation, Inc.\n"
1: (599) ->~"License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html\nThis is free software: you are free to change and redistribute it.\nThere is NO WARRANTY, to the extent permitted by law. Type \"show copying\"\nand \"show warranty\" for details.\n"
1: (599) ->~"This GDB was configured as \"x86_64-redhat-linux-gnu\".\nFor bug reporting instructions, please see:\n"
1: (599) ->~"http://www.gnu.org/software/gdb/bugs/.\n"
1: (599) ->(gdb)
1: (605) <-1001-gdb-set target-async on
1: (606) ->1001^done
1: (606) ->(gdb)
1: (608) 1001: elapsed time 3
1: (614) <-1002-interpreter-exec console "set pagination off"
1: (618) ->=cmd-param-changed,param="pagination",value="off"
1: (618) ->1002^done
1: (618) ->(gdb)
1: (618) 1002: elapsed time 4
1: (618) <-1003-gdb-set solib-search-path ~/builds/proj/bin:
1: (619) ->1003^done
1: (619) ->(gdb)
1: (619) 1003: elapsed time 0
1: (619) <-1004-file-exec-and-symbols ~/builds/proj/bin/test
1: (620) ->1004^done
1: (620) ->(gdb)
1: (621) 1004: elapsed time 1
1: (623) <-1005-interpreter-exec console "show architecture"
1: (624) ->~"The target architecture is set automatically (currently i386)\n"
1: (624) ->1005^done
1: (624) ->(gdb)
1: (625) 1005: elapsed time 1
1: (628) <-1006-target-attach 13550
1: (629) ->1006^error,msg="ptrace: Operation not permitted."
1: (629) ->(gdb)
1: (631) 1006: elapsed time 3
1: (640) <--gdb-exit
E output: {"category":"telemetry","output":"VS/Diagnostics/Debugger/Attach","data":{"VS.Diagnostics.Debugger.ImplementationName":"Microsoft.MIDebugEngine","VS.Diagnostics.Debugger.EngineVersion":"14.0.50106.1","VS.Diagnostics.Debugger.HostVersion":"1.0.40106.1","VS.Diagnostics.Debugger.AdapterId":"cppdbg","VS.Diagnostics.Debugger.Attach.Message":"Unable to start debugging. Attaching to process 13550 with GDB failed because of insufficient privileges with error message 'ptrace: Operation not permitted.'.\r\n\r\nTo attach to an application on Linux, login as super user or set ptrace_scope to 0.\r\nSee https://aka.ms/miengine-gdb-troubleshooting for details.","VS.Diagnostics.Debugger.Attach.IsError":true},"type":"output"}
R: {"success":false,"message":"Unable to start debugging. Attaching to process 13550 with GDB failed because of insufficient privileges with error message 'ptrace: Operation not permitted.'.\r\n\r\nTo attach to an application on Linux, login as super user or set ptrace_scope to 0.\r\nSee https://aka.ms/miengine-gdb-troubleshooting for details.","request_seq":2,"command":"attach","body":{"error":{"id":1104,"format":"Unable to start debugging. Attaching to process 13550 with GDB failed because of insufficient privileges with error message 'ptrace: Operation not permitted.'.\r\n\r\nTo attach to an application on Linux, login as super user or set ptrace_scope to 0.\r\nSee https://aka.ms/miengine-gdb-troubleshooting for details.","variables":null}},"running":false,"refs":null,"seq":0,"type":"response"}
C disconnect: {"restart":false}
R: {"success":true,"message":null,"request_seq":3,"command":"disconnect","body":null,"running":false,"refs":null,"seq":0,"type":"response"}

[puchodr]

That's a gdb error message. When I run sudo gdb --pid 13550 I'm able to debug my process. It seems like VS Code isn't falling back to using sudo for whatever reason.

[pieandcakes]

It would be our debug adapter layer, not VS Code. I wonder why it isn't elevated, but I'd have to setup a test machine to verify. Like I said above we use pkexec and fall back to a call to sudo to try and elevate but it seems like it isn't happening in this instance and I don't know why.

The other workaround would be to set ptrace_scope to 0 which would allow you to attach to any process, which should get you past this problem, but this seems like a different error compared to the first problem you are running into. AFAIK VS Code also says they don't support running under root but I don't know what issues you would run into when doing that.

[puchodr]

Any update on either scenario?

[bboudrea]

I'm having the exact same issue running VS code 1.21.1 on Centos 7. I have an executable that needs to be run as root, so I've launched the VS Code application as a Superuser using sudo. I've been able to get the executable to successfully build, but when I try to run and debug it I get the error "Unable to start debugging. Failed to initialize debugger terminal." Because of what @puchodr said, I opened up the exact same workspace (with the exact same launch.json file) in VS Code launched as a normal user, and the debugger worked without a problem (the code failed very shortly in because it wasn't being run as root, but the debugger did function properly and hit the first breakpoint I specified).

So, it does appear there may be an issue of VS Code having difficulty launching a debugger with root privileges? To my understanding this should be supported, I didn't see anything in the docs saying this functionality doesn't exist but of course I could be mistaken.

It seems this issue is at least being looked into which is great, but I figured it couldn't hurt to share that I'm experiencing a similar problem. Thanks for the help!

In case it's needed, here is the copy of my launch.json file:

[puchodr]

I’m still experiencing the same thing as well. I’ve basically given up trying things until there’s some solution to this.

[bboudrea]

@puchodr have you ever opened a new issue regarding this topic or looked around github to see if anyone else has had this same problem? I'm wondering if @pieandcakes lost track of this thread since he was initially incredibly responsive and it appears we're following up under an issue that's marked as closed.

[pieandcakes]

@bboudrea @puchodr VS Code itself doesn't support running in sudo mode. If that is a requirement, they need to make changes to VS Code first to fix any issues there. I've been busy with other work and haven't had a chance to debug this yet to see what the problem might be but it is on the list of items to look at when I have free time but I suspect that there will need to be work on their side to support the scenario before we can get much further.

[puchodr]

Running VS Code in sudo would be a workaround if it worked. But the real issue is that I can't debug a root-process with VS Code running as a user-process. I have two different setups, Ubuntu and RHEL. Ubuntu seems to handle this scenario properly but VS Code running in RHEL fails to create a terminal.

[pieandcakes]

@puchodr I'll have to see if between @WardenGnaw and I we can try this out on RHEL. That isn't a distro that I've tried the extension on recently.

[frsauvage]

I have the same issue. I tried already every solution described here unsuccessfully.
I am on RHEL, which is offline because I am on a military site.
I should be root on VSCode (Insiders) as the commands (freeipmi c librairie) are used as root.
any help will be graceful
Francine

[thejinx0r]

I also had this problem on ubuntu 18.04.
I had installed it with snap, but then I uninstalled it and reinstalled with the .deb package.

[malchera]

Any updates on this matter? Still not working for RHEL7.4. sudo is not an option for me, as I am working on a cluster.

I'd vote for reopening this issue as this does not seem to be fixed.

[yamcenutzer]

this used to work but I forgot how far back that was, obviously earlier than the oldest 17.3 version that is available from releases.
also using Centos/RHEL 7.xx

[mattaereal]

I'm using Arch Linux updated to date, and I'm having the same issues described above.

[pieandcakes]

Can any of you who are not running into the RHEL sudo issue see if this comment fixes your problem?

[pieandcakes]

For the RHEL/Centos problem, I filed a new issue: #2493

[gabrieldelaparra]

Can any of you who are not running into the RHEL sudo issue see if this comment fixes your problem?

Nope. At least I do not have the .real.

[mattaereal]

That gnome-real thing is like super weird, I've been using gnome since ages and never saw another gnome-terminal besides the default one :/. Also, modifying system applications like that in order to fix something else does not seem the correct way to deal with it.

[tobiasmelcher]

I also cannot attach via gdb to a running process when running visual studio code in a vnc session on linux at display :1 . gnome-terminal and xterm apps are located in /usr/bin and can be launched (there is no .real file). I assume visual studio code is tryting to launch the terminal at the wrong display. Setting the DISPLAY variable to :1 doesn't help.
Any suggestions?

[pieandcakes]

@tobiasmelcher your scenario sounds a bit different. You are VNCing into a Linux machine and then launching VS Code and it can't debug? Attaching should not be using a terminal at all since the terminal is where you ran the program you are attaching to. Can you help clarify what you are asking?

[tobiasmelcher]

Yes, exactly. I connect to a remote Linux machine via vncviewer and launch then VS code inside the vnc session. C++ toolingis working great, but gdb debugging inside VS code is not working for me. I get the here mentioned error message "failed to initialize debugger terminal". As workaround, I can debug using lldb like described here; but I would prefer using gdb.