microsoft
RedHat/CentOS el7.x86_64 - GDB: Failed to set controlling terminal; Creates a file with name "2"
Originally posted by @FranzDeCopenhague in https://github.com/Microsoft/vscode-cpptools/issues/264#issuecomment-352234542
I am also seeing this in CentOS 7.
My launch.json:
{
"version": "0.2.0",
"configurations": [
{
"name": "(gdb) Launch",
"type": "cppdbg",
"request": "launch",
"program": "${workspaceFolder}/build/bin/syshealth",
"args": [],
"stopAtEntry": false,
"cwd": "${workspaceFolder}/build/bin",
"environment": [],
"externalConsole": true,
"MIMode": "gdb",
"setupCommands": [
{
"description": "Enable pretty-printing for gdb",
"text": "-enable-pretty-printing",
"ignoreFailures": true
}
],
"preLaunchTask": "build"
}
]
}
My c_cpp_properties.json:
{
"configurations": [
{
"name": "Linux",
"includePath": [
"${workspaceFolder}/**"
],
"defines": [
"_DEBUG",
"UNICODE"
],
"compilerPath": "/usr/bin/gcc",
"cStandard": "c11",
"cppStandard": "c++11",
"intelliSenseMode": "clang-x64",
"compileCommands": "${workspaceRoot}/build/compile_commands.json"
}
],
"version": 4
}
When I try to launch the debugger, I get a terminal window that appears that says: &"warning: GDB: Failed to set controlling terminal: Operation not permitted\n".
The VSCode debugger is inoperable:
- Clicking on the pause button produces no results (only restart and stop do)
- the debug console prints
Unable to perform this action because the process is running.no matter what GDB command I send. - no variables or symbols appear in the debug pane.
Another interesting symptom is that a file with the name "2" appears in my build/bin directory with the contents -e c 1. This file only appears after I attempt to launch a debugging session.
Running GDB standalone from a separate terminal session doesn't seem to have any problem.
If you enable logging, you will see the command we put in a file that we tell VS Code to run. Can you see if that command looks ok?
This seems to stem from this line of code although I don't know why that line ends up creating a file. This command is to clear the terminal.
I apologize for the delay in getting back to this issue. I wonder if this has anything to do with tcsh not working with all the bash-isms such as redirection in the form 1>&2.
On CentOS 7 shell is not a recognized command.
The only way the command worked for me was to change it to be
sh -c 'echo -e \\033c 1>&2'
In the file that you referenced, there are several other references to shell that may need to be changed to sh -c '<command>'. I am not sure how portable this is with macOS and other versions of Linux.
From my brief research it doesn't appear that C-shells (such as tcsh) support redirection very well. Unfortunately RHEL and CentOS still default to tcsh. Fortunately, it does appear that /bin/sh still points to bash.
@esarver shell isn't a shell console command but rather a command to gdb to run the rest of that command in its default shell.
these commands are sent to gdb which then sends it to the shell. You can test it out by running gdb --interpreter=mi and then running -interpreter-exec console <cmd> where <cmd> is shell echo -e \\033c 1>&2.
@esarver
shellisn't a shell console command but rather a command togdbto run the rest of that command in its default shell.these commands are sent to
gdbwhich then sends it to the shell. You can test it out by runninggdb --interpreter=miand then running-interpreter-exec console <cmd>where<cmd>isshell echo -e \\033c 1>&2.
my default shell is tcsh in centos 7, execute command(-exec shell echo -e \033c 1>&2) in vscode debug console like this, it do generate a file with name "2" in the current dir
according to gdb doc On GNU and Unix systems, the environment variable SHELL, if it exists, determines which shell to run.
and my $SHELL is tcsh 
since redirection like this "1>&2" does not work in tcsh, it seems that the echo command(echo -e \033c 1>&2) need to take into account different kinds of shell redirection syntax.
