"warning gdb failed to set controlling terminal operation not permitted" when launching a GUI application.

[delmyers]

Forked from #115

I am using: •Ubuntu 16.04 (I know it is not supported officially) •Latest VSCode version •Latest "C/C++ for VSCode" version

My project structure looks like this: •/home/lvier/mainProject/fooProject (source code) •/home/lvier/mainProject/build/fooProject (binaries)

I am working in the sub-project "/home/lvier/mainProject/fooProject" and in "/home/lvier/mainProject/build/fooProject" there are many sub programs (lets say "foo", "foo_sub1", "foo_sub2" ...).

My goal: I want to start the program "foo" (which starts all other foo_sub-programs) and then, I want to debug a certain sub program (let's say "foo_sub1") by attaching to it. I am also fine with starting and debugging in the same time as long as I can debug the sub-program "foo_sub1". The main project itself does not contain any executables.

2.Assume that "foo" is not running yet. When using the "C++ Launch"-config, the program starts but no UI elements appear. Instead, it starts with a new terminal popping up which says "warning gdb failed to set controlling terminal operation not permitted" for a brief moment and in the internal console of VSCode, it states that it stops at a certain line of code (a breakpoint not defined by me) and prints "Stopped due to shared library event (no libraries added or removed) Loaded '/lib64/ld-linux-x86-64.so.2'. Symbols loaded. [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1"." From there I can't continue further and I have to manually terminate the program.

When I use GDB without VSCode, i.e. just by native terminal, my program is starting properly but with VSCode, there seem to be some issues currently.

This is my current, autogenerated config where I only edited the "cwd" and "program" paths (assume that the environment variable "${env.build_foo}" is set to "/home/lvier/mainProject/build/fooProject"):

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "C++ Launch",
            "type": "cppdbg",
            "request": "launch",
            "targetArchitecture": "x64",
            "program": "${env.build_foo}/foo",
            "args": [],
            "stopAtEntry": false,
            "cwd": "${workspaceRoot}",
            "environment": [],
            "externalConsole": true,
            "linux": {
                "MIMode": "gdb"
            },
            "osx": {
                "MIMode": "lldb"
            },
            "windows": {
                "MIMode": "gdb"
            }
        },
        {
            "name": "C++ Attach",
            "type": "cppdbg",
            "targetArchitecture": "x64",
            "request": "launch", // <-- "attach" is not allowed (anymore)! :(   
            "program": "${env.build_foo}/foo_sub1",
            "args": [],
            "stopAtEntry": false,
            "cwd": "${workspaceRoot}",
            "environment": [],
            "processId": "${command.pickProcess}",
            "externalConsole": false,
            "linux": {
                "MIMode": "gdb"
            },
            "osx": {
                "MIMode": "lldb"
            },
            "windows": {
                "MIMode": "gdb"
            }
        }
    ]
}

[delmyers]

@LVier I've forked this issue from your original bug #115. Unfortunately, we can't repro it. Can you help us investigate it a bit? There is a way to enable logging for our debug engine, which can help us to track down the issue.

Please open your package.json file for the cpp tools extension:

~./vscode/extensions/Microsoft.cpptools-<version>\package.json

look for the following snippet:

"runtime": "./debugAdapters/corerun",
"runtimeArgs": [],
"program": "./debugAdapters/OpenDebugAD7.dll",
 "initialConfigurations": [

Just after the program line and before he initialConfigurations line, add this:

"args": ["--engineLogging=/home/<username>/log.txt"],

So, it will look like this:

"runtime": "./debugAdapters/corerun",
"runtimeArgs": [],
"program": "./debugAdapters/OpenDebugAD7.dll",
"args": ["--engineLogging=/home/<username>/log.txt"],
 "initialConfigurations": [

You should end up with a log at the location /home/<username>/log.txt. If you give us the text in that file, it will help our investigation.

[LFishi]

Sure, I may investigate it again this weekend and will inform you asap.

[ampatel21]

I get that exact error if my user shell is tcsh. No problems using bash.

[delmyers]

@LVier, @ampatel21, we are you still seeing this issue? We are unable to repro it, and your logs would be a great help.

[LFishi]

@delmyers I am sorry I didn't response at all. My primal focus was the project which is over now but I will see these days if I can still reproduce the problem. Stay tuned

[chaneyw]

I think I am experiencing this same bug but the above comments about enabling logging no longer seem to apply (the .json file has changed format, editing the "variables" line for the .dll instead causes VS Code to want to reinstall the extension which deletes any change made)

I am getting a popup console that says "warning gdb failed to set controlling terminal operation not permitted" and a debug window message

Stopped due to shared library event (no libraries added or removed) Loaded '/lib64/ld-linux-x86-64.so.2'. Symbols loaded. [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Breakpoint 1, main (argc=4, argv=0x7fffffffda68) at ((breakpoint here that I didn't set)) 184 int main(int argc, char **argv) { [Inferior 1 (process 29851) exited with code 01]

[chaneyw]

It seems to be crashing on gflags::ParseCommandLineFlags(). Programs not using gflags are functioning. Breakpoint in main() before ParseCommandLineFlags and it will run up to this point.

[dsanz006]

Similar issue here: When executing my C++ GUI application, I get the following first line on the terminal window:

&"warning: GDB: Failed to set controlling terminal: Operation not permitted\n"

I also get a new file created in the execution directory, named "2". The content of this file is: "-e c 1".

I only get it if I execute it from inside VSCode, not if I execute it manually from an external terminal. Apart from this, I would like to output my console messages on the VSCode terminal window, and not open a new terminal window every time. But this doesn't seem to be possible right now on Linux...

[cprada87]

@dsanz006 You fix it? If you have not, Any other way besides terminal?

[dsanz006]

I haven't fixed it, still happening, and couldn't find any alternative solution

[reporter123]

The message seems to only happen if using something other than bash as the default shell.

[iamJunPan]

Any update on this issue? i also ran into it. Or somebody give me a workaround? Many thanks.

[reporter123]

The workaround is to set bash as the default shell in the latest vscode it is possible to set "terminal.integrated.automationShell.linux"="bash" which sets this only for vscodes automation. This resolves the issue for me.

[ghita]

Happening same thing to me. Very hard to make this work, remote debugging to work in WSL. At some point I saw in wsl that there were multiple opened debugging instances for same executable, some leftovers but don't know if that is the issue.

[NathanIceSea]

Running Manjaro Linux and this is happening on bash, not many tweaks been done to the os.

[aleksasp]

Trying to debug c++ console app from within container running on a remote host. Remote host is accessed via ssh. Same problem, terminal output:

&"warning: GDB: Failed to set controlling terminal: Operation not permitted\n"
&"Cannot create process: Operation not permitted\n"

Debug console output:

=thread-group-added,id="i1"
GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-120.el7
Copyright (C) 2013 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-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Warning: Debuggee TargetArchitecture not detected, assuming x86_64.
=cmd-param-changed,param="pagination",value="off"
=cmd-param-changed,param="args",value="HIDDEN_PARAMS"
ERROR: Unable to start debugging. Unexpected GDB output from command "-exec-run". During startup program exited with code 127.
The program 'HIDDEN_EXECUTABLE_PATH' has exited with code 0 (0x00000000).

Setting following values did not help. /home/USERNAME/.config/Code/User/settings.json

    "terminal.integrated.defaultProfile.linux": "bash",
    "terminal.integrated.automationShell.linux": "bash",

Environment:

Remotely hosted container image: Centos 7 Remote host OS: Centos 7 Host OS: Ubuntu 18.04 VSCode version: 1.56.1 Project type: CMake

[prophetw]

After this message "warning gdb failed to set controlling terminal operation not permitted" appears, I set a breakpoint ,and vscode goes to the breakpoint. It seems these warnings is waiting for me to set a NEW breakpoint. --- Setting breakpoint after these warnings appears solve my problem. Hoping to help somebody. My env: vscode ssh ubuntu20.04 zsh

[langong347]

For Linux users, if you see an error like this:

<your login shell: blah blah blah>
&"warning: GDB: Failed to set controlling terminal: Operation not permitted\n"
&"Cannot create process: Operation not permitted\n"

make sure you change your login shell to bash if it's not the default. Setting this through VSCode is not enough.

[PetrosKoulouridis]

I face the same issue, the debug console says "stopped due to shared library event" while a popup terminal says the "failed to set..."message you all mention. However, setting a new breakpoint manually (by clicking on it) does absolutely nothing, while doing it through the debug console gives me the exception "stopped due to unknown breakpoint" Hoping someone can help, because under these circumstances I can only step line by line in debugging mode.

[al-zatv]

Also have this problem. Login shell: bash; host:ubuntu 20.04, remote-ssh: ubuntu 18.04 inside of docker at centos. (gcc 7.4.0, gdb 8.1.1) Setting the breakpoint does not help. "Run without debugger" also don't help.

update: in my case, problem was:

• remote vscode-cpp in docker
• but, docker was made without necessary priviledge --cap-add=SYS_PTRACE or --privileged

See here: https://github.com/Microsoft/MIEngine/wiki/Troubleshoot-attaching-to-processes-using-GDB So, now I can debug.

[thaynewalker]

I noticed this problem when I had compiled without symbols (-g). After rebuilding with symbols I was able to use the debugger without any issues. (Posting this in case it helps anyone.)

[Musta-Pollo]

I indeed missed the -g parameter. Thank you!

[ares89]

I noticed this problem when I had compiled without symbols (-g). After rebuilding with symbols I was able to use the debugger without any issues. (Posting this in case it helps anyone.)

i add this to CMakeLists.txt, and it works for me

set(CMAKE_BUILD_TYPE Debug)

[taoqf]

Trying to debug c++ console app from within container running on a remote host. Remote host is accessed via ssh. Same problem, terminal output:

&"warning: GDB: Failed to set controlling terminal: Operation not permitted\n"
&"Cannot create process: Operation not permitted\n"

Debug console output:

=thread-group-added,id="i1"
GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-120.el7
Copyright (C) 2013 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-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Warning: Debuggee TargetArchitecture not detected, assuming x86_64.
=cmd-param-changed,param="pagination",value="off"
=cmd-param-changed,param="args",value="HIDDEN_PARAMS"
ERROR: Unable to start debugging. Unexpected GDB output from command "-exec-run". During startup program exited with code 127.
The program 'HIDDEN_EXECUTABLE_PATH' has exited with code 0 (0x00000000).

When I run devcontainer on mac, got same logs like this.

[MartyMcFlyInTheSky]

It was also debug symbols missing for me. Added -DCMAKE_BUILD_TYPE=Debug to cmake configure, now it works

[saifaskri]

it works for me after selecting the default bash in my remote machine as it is in the Pictures

[Stargazer1209]

Workload: vscode from win11 connected to wsl 2 default distro ubuntu 22.04 It's 2024 now and I run into the same problem, long before this problem occured I change the default shell of vscode and wsl2 to pwsh, at that time it worked fine for me. But after one or two months this problem suddenly appears for no reason even if I debug a single cpp file which ran smoothly before. Changing the default and login shell back to bash also does not solve this problem. Vscode itself, related extensions and all packages on wsl2 have been updated to newest version.

[Stargazer1209]

Terminating all vscode related process on the host where gdb runs and reopening the project solved my problem! Since terminating those server process one by one is kinda exhausting, I had to reboot my machine, but finally it worked. This approach is offered by @jqknono.

I encounter this problem, too. These ways do not work for my situation:

• Restart vscode

• Reboot linux

• Downgrade gdb version from 12.1 to 9.2

finally, this is about the vscode-server. I am working on a remote linux, even though I terminate all the vscode windows, there are still many process about vscode like this:

Just terminate them one by one, then start your project again, it's OK now.

Originally posted by @jqknono in #11173

What's more, this is OBVIOUSLY a problem with vscode (server, wsl2 components, etc) itself instead of gdb where you can't use vscode debug control bar to step through or terminate the program when this happend while manually run gdb from shell works fine. When I got this problem, output from vscode server(remote) reported several errors, if necessary to fix this, I would try to reproduce these error and paste them to the related issue.

[qiaorunpu]

it works for me after selecting the default bash in my remote machine as it is in the Pictures

Thanks，I trans from zsh to bash and it works like a charm. The warning '&"warning: GDB: Failed to set controlling terminal: Operation not permitted\n" ' still pop up ,but I still can use breakpoint.

[intractabilis]

It started happening to me. I am using Arch, GDB 17. The default terminal profile and login shell are bash. I am launching a console application, not GUI. GDB without VS Code works without warnings.