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"
}
}
]
}
@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.
Sure, I may investigate it again this weekend and will inform you asap.
I get that exact error if my user shell is tcsh. No problems using bash.
@LVier, @ampatel21, we are you still seeing this issue? We are unable to repro it, and your logs would be a great help.
@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
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]
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.
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...
@dsanz006 You fix it? If you have not, Any other way besides terminal?
I haven't fixed it, still happening, and couldn't find any alternative solution
The message seems to only happen if using something other than bash as the default shell.
Any update on this issue? i also ran into it. Or somebody give me a workaround? Many thanks.
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.
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.
Running Manjaro Linux and this is happening on bash, not many tweaks been done to the os.
Most helpful comment
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.