Reputation: 516
I've been working with remote-ssh on a raspberry and c/c++ extension without any issue, all of a sudden I cannot start the debugger. Nothing changed, configuration files are the same as before but now when I start the debugger, I see for a couple of seconds the top debugging bar and then it disappears. No message on the console, nothing.
For this purpose, I created a simple project from scratch, and even there, the same issue appears.
To Reproduce launch.json
{
"version": "0.2.0",
"configurations": [
{
"name": "(gdb) Launch",
"type": "cppdbg",
"request": "launch",
"program": "${workspaceFolder}/a.out",
"args": [],
"stopAtEntry": false,
"cwd": "${workspaceFolder}",
"environment": [],
"logging": { "engineLogging": true },
"externalConsole": true,
"MIMode": "gdb",
"miDebuggerPath": "/usr/bin/gdb",
"setupCommands": [
{
"description": "Enable pretty-printing for gdb",
"text": "-enable-pretty-printing",
"ignoreFailures": false
}
]
}
]
}
main.c
#include <stdio.h>
int main(){
printf("ciao\n");
return 1;
}
Compile with gcc -g main.c
As I stated before, this workflow worked for me, from one second to another it stopped working as intended and I have no idea why and how to fix it, any help is appreciated.
I have tried with the wsl-remote extension and it is working as expected.ù
Tried to uninstall gdb from host and launch the debug session, the message "gdb" not found does not even appear as it should
Upvotes: 14
Views: 34008
Reputation: 139
For me this did the trick:
Upvotes: 1
Reputation: 61
I just had the same problem when I was debugging C++ in a container. I created the launch.json file in the container, which created it on the host machine as root (because the source code was mounted into the container from the host and I was root in the container). I then started another container and the debugger wouldn't launch. I realized the owner of launch.json was root, so on a haunch I changed the owner from the host machine to my usual user, restarted vs code, and now it's working.
Upvotes: 0
Reputation: 807
I had the same problem (though the debug bar would show up for a second and then disappear). I was using a conda env with python 3.6. I updated to 3.8, with the same dependencies, and it started working.
Upvotes: 0
Reputation: 532
This may be caused by a faulty installation of the VS Code C/C++ extension. When launching VS Code, if the message "Unable to start the C/C++ language server. IntelliSense features will be disabled" appears, this is probably the cause. Was able to fix the installation in this case by installing a previous version of the C/C++ extension as per this answer.
Upvotes: 0
Reputation: 236
I was in similar situation and couldn't find relevant resolutions:
Quick Answer: After upgrade to VS Code 1.56.2, make sure to remove old breakpoints and create new breakpoint and at-least have 1 breakpoint and launch.json available.
Lengthy details:
I have similar issue for python scripts when I start the "debugger bar" I see it for a couple of seconds the top debugging bar and then it disappears. Bu then no message on the console, nothing. I tried reinstalling VS Code, enabling/disabling extension, various restart.
RootCause:
What I did know for sure that I updated my VS Code, and after that this mysterious issue start happening, so when to release log of VS Code 1.56.2. I found below release log
Debug view displayed on break#
The default value of the debug.openDebug setting is now openOnDebugBreak so that on every breakpoint hit, VS Code will open the Debug view. The Debug view is also displayed on first session start.
So VS code Version 1.56 release, debugger will only show when at-least 1 breakpoint is found. However, looks like there is issue with their internal code checking for historical breakpoint data after VS Code upgrade..
https://code.visualstudio.com/updates/v1_56#_debug-view-displayed-on-break
Upvotes: 6