Environment
Ubuntu 20.04.
VS Code 1.69.0 with extensions
VS Code launch.json:
{
"version": "0.2.0",
"configurations": [
{
"name": "Test debug",
"type": "cppdbg",
"request": "launch",
"program": "${workspaceRoot}/bazel-bin/app/mp_test",
"stopAtEntry": false,
"cwd": "${workspaceFolder}",
"externalConsole": true,
"MIMode": "gdb",
"setupCommands": [
{
"description": "Enable pretty-printing for gdb",
"text": "-enable-pretty-printing",
"ignoreFailures": true
}
],
}
]
}
Note: I use bazel to build mediapipe and my app. Do not know if it matters or not.
bazel build --copt="-g" --strip="never" --define MEDIAPIPE_DISABLE_GPU=1 //app:mp_test
Problem description
I have a code:
mediapipe::CalculatorGraph graph;
graph.Initialize(config);
I set breakpoints on the second line. Start debugging. After F11 (step into) execution cursor stands on the line. I repeated several time F11 and at the end it goes into some standard library code (unique_ptr exactly). I tried to use Stack Trace and double click on one of its entries. Look at the screenshot. So, debugger cann't open the source file, because it looks into /proc/self/cwd/external folder which doesn't exists. Meanwhile IntelliSence can find the definition of the mediapipe::CalculatorGraph::Initialize in mediapipe project directory and my app was built successfully, means that compiler (linker) found everything. Why? How can I fix it?
Note: Folder /proc/self/cwd/ contains files from my app folder (BUILD, main.cpp, ...).
Related
On trying to debug a C++ code on VSCode, I am getting the error, "No client URI found in getBuildTasks()"
I am an absolute beginner and am just learning C++ and just set up my VSCode from a tutorial to run C++ on VSCode with minGW-w64. But the debug button just won't work like it should have and is instead throwing that error.
This is what my launch.json looks like:
"version": "0.2.0",
"configurations": [
{
"name": "(gdb) Launch",
"type": "cppdbg",
"request": "launch",
"program": "${workspaceFolder}/a.exe",
"args": [],
"stopAtEntry": false,
"cwd": "${workspaceFolder}",
"environment": [],
"externalConsole": false,
"MIMode": "gdb",
"miDebuggerPath": "C:\\Program Files\\mingw-w64\\x86_64-8.1.0-posix-seh-rt_v6-rev0\\mingw64\\bin\\gdb.exe",
"preLaunchTask": "echo",
"setupCommands": [
{
"description": "Enable pretty-printing for gdb",
"text": "-enable-pretty-printing",
"ignoreFailures": true
}
]
}
]
}
And these are the options that show up when I press Run and Debug with a.cpp opened in the folder with the .vscode subfolder containing the aforementioned launch.json file along with c_cpp_properties.json and tasks.json files.
Any and all help will be appreciated.
You need to open the Folder that you're working in, into the Workspace.
To do this, select Explorer from the left side bar and click on the big blue Open Folder button over there and open the Folder that you're working on and containing the .vscode subfolder.
.
.
The Desktop is where I build most of my smaller, quicker programs at. I removed the Desktop from the WorkSpace open, in order to stop the Source Control from suggesting me to commit changes to GitHub and hence VSCode had no directory to find the .vscode folder from. This never was a problem when I would debug and run python files but for C++ it was.
It was an absolute nooby dumbo mistake of mine but it literally took me 2 days to figure out and I've written the answer down, hoping it helps some other noob. :)
I'm at a bit of a loss here, I hadn't really expected this to be difficult. I usually work on Linux, but today I had some work that I needed to do and only had a Windows machine. I thought this would be no problem, I can install git for windows, clone my project, and get right to work. Its just been a huge mess. I'm really hoping someone can help me understand where I went wrong in setting all this up on Windows. It isn't something I plan to do frequently, but definitely something I want to be able to do on a Windows machine in a reasonable amount of time.
I'm using WSL and have set my default VSCode Windows integrated terminal to C:\WINDOWS\System32\bash.exe
I installed Windows 10 SDK to fix crtdbg.h include errors as a dependency against <iostream>
I installed gdb with MinGW -
I set the path environment variable
I created a launch.json -
{
// Use IntelliSense to learn about possible attributes.
// Hover to view descriptions of existing attributes.
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
{
"name": "(gdb) CDLL Driver",
"type": "cppdbg",
"request": "launch",
"program": "${workspaceFolder}/driver",
"args": [],
"stopAtEntry": false,
"cwd": "${workspaceFolder}",
"environment": [],
"externalConsole": false,
"MIMode": "gdb",
"miDebuggerPath": "C:\\MinGW\\bin\\gdb.exe",
"setupCommands": [
{
"description": "Enable pretty-printing for gdb",
"text": "-enable-pretty-printing",
"ignoreFailures": true
}
]
}
]
}
My MinGW bin contains the following
I launch my debug task in VSCode and I get the following error
cmd /C "c:\Users\shaun\.vscode\extensions\ms-vscode.cpptools-0.28.2\debugAdapters\bin\WindowsDebugLauncher.exe --stdin=Microsoft-MIEngine-In-4n4ohh2f.ibt --stdout=Microsoft-MIEngine-Out-1irudlfy.q5x --stderr=Microsoft-MIEngine-Error-fg20cagk.ynl --pid=Microsoft-MIEngine-Pid-kzdzn4p4.lro --dbgExe=C:\MinGW\bin\gdb.exe --interpreter=mi "
Command 'cmd' not found, but there are 16 similar ones.
I can provide more information if needed. I'm really hoping I missed something simple here that would be obvious to someone who works on Windows.. Thank you in advance, I really appreciate the help!
If you are using WSL to compile the project you should not use MinGW gdb.
You need to install gdb on you Linux subsystem (using native tools like apt if you are using Ubuntu WSL), reopen your project in WSL and configure the WSL path to gdb.
I was able to successfully debug using this setup on WSL.
Replace your launch.json file with this file
{
"version": "0.2.0",
"configurations": [
{
"args": ["1"],
"name": "gcc.exe - Build and debug active file",
"type": "cppdbg",
"request": "launch",
"program": "${fileDirname}\\${fileBasenameNoExtension}.exe",
"stopAtEntry": false,
"cwd": "${fileDirname}",
"environment": [],
"externalConsole": true,
"MIMode": "gdb",
"miDebuggerPath": "C:\\MinGW\\bin\\gdb.exe",
"setupCommands": [
{
"description": "Enable pretty-printing for gdb",
"text": "-enable-pretty-printing",
"ignoreFailures": true
}
],
"preLaunchTask": "C/C++: gcc.exe build active file"
}
]
}
Make Sure you have installed MinGw Compiler and gdb debugger
We are developing a Win64 DLL using the GCC toolchain (MinGW-w64) in version 9.2.0. As IDE we use VisualStudio Code (version 1.47.3) with the C/C++ IntelliSense, debugging, and code browsing plugin from Microsoft (version 0.30.0).
Unfortunately, we cannot set any breakpoints inside our DLL.
The situation is the same if we attach the DLL within our TestApplication statical or dynamical by using LoadLibrary.
Starting the GDB as a console process allows us to set a breakpoint in the DLL and stop at that line, but we miss the convenience of the IDE. I assume there is an issue in the configuration of the VSCode project or within the C/C++ plugin.
We use the following launch.json file:
"version": "0.2.0",
"configurations": [
{
"name": "gcc.exe build and debug active file",
"type": "cppdbg",
"request": "launch",
"program": "${workspaceFolder}/Win64/TestApplication.exe",
"args": [],
"stopAtEntry": true,
"cwd": "${workspaceFolder}",
"environment": [],
"externalConsole": true,
"MIMode": "gdb",
"miDebuggerPath": "${workspaceFolder}/minGW-w64/bin/gdb.exe",
"setupCommands": [
{
"description": "Enable pretty-printing for gdb",
"text": "-enable-pretty-printing",
"ignoreFailures": false
}
],
"preLaunchTask": "build-all",
"avoidWindowsConsoleRedirection": true,
"logging": {
"trace": false,
"traceResponse": false,
"engineLogging": true
}
}
]
}
Update: 17-Aug-2020:
The reason is the missing symbols from the DLL, which cannot be loaded.
Even if I try to load the symbol file for the DLL while the debugger is starting, it always removes these symbols when loading the host application. The only workaround that I have found is to manually reload the symbol file within a first breakpoint that I can only enter by its address.
Is anybody able to debug a Win64 DLL with the same toolchain?
I'm trying to do remote debugging of bazel project in docker.
Local plugins: Remote Development
Docker plugins (defined in devcontainer.json): ms-vscode.cpptools
My launch.json
{
"version": "0.2.0",
"configurations": [
{
"name": "Debug",
"type": "cppdbg",
"MIMode": "gdb",
"request": "launch",
"args": [],
"stopAtEntry": true,
"cwd": "${workspaceFolder}",
"program": "/root/.cache/bazel/_bazel_root/e53bbb0b0da4e26d24b415310219b953/execroot/tf_serving/bazel-out/k8-dbg/bin/tensorflow_serving/fplugin/fserve_cc",
"externalConsole": false,
}
]
}
However I'm getting an error:
Unable to open 'fserve.cc': Unable to read file 'vscode-remote://dev-container+2f55736572732f6d67756d6f77736b2f776f726b2f6f766d732d63/proc/self/cwd/tensorflow_serving/fplugin/fserve.cc
In local development I would add sourceFileMap, however it doesn't seem to work for remote docker development. Any ideas?
when you try to compile with bazel, you will have 4 soft link(bazel-bin, bazel-{source-folder}, bazel-out, bazel-testlog)
modify this attribute wi
"cwd": "${workspaceFolder}/bazel-",
I'm not sure that your problem is due to remote debugging. I believe that the following info will work whether or not you're in a remote environment.
Bazel generates a few symlinks in your project's root folder that contain useful data (for more see the docs):
bazel-bin is a symlink to a folder in the output directory that contains generated code and binaries for the latest configuration of the build you've run.
bazel-{folder-name} is a symlink to the execRoot, which is how bazel sees your project's source code. {folder-name} is the name of the folder your project is in.
bazel-out is a symlink to bazel's output root.
bazel-testlog is a symlink to the outputs from test runs
If you're not using bazel's runfiles library
To provide VSCode with sources at the right location, modify the "cwd" attribute in launch.json to:
"cwd": "${workspaceFolder}/bazel-{folder-name}",`
If you are using runfiles
You're using runfiles if your program requires files in a data attribute in any of its dependencies
First, set "cwd" to the root of the runfiles tree for your binary, and then set "sourceFileMap" in a way that maps the current working directory to the execRoot symlink. For me (on linux), /proc/self/cwd maps correctly, but that might not be true for you. I was able to tell that I got it wrong because VSCode complained about being unable to read a file at /proc/self/cwd/external/external-project/src/file.cpp.
"cwd": "${workspaceFolder}/bazel-bin/path/to/executable/executable.runfiles/{workspace-name}`,
"sourceFileMap": {
"/proc/self/cwd": "${workspaceFolder}/bazel-{folder-name}`,
},
{workspace-name} can be found in WORKSPACE, it will look like workspace(name = "my-project"). If there is no workspace name defined in that file, it defaults to __main__.
I might also recommend changing the "program" attribute to a more convenient location. If the last thing you did was build your binary with bazel, you can find the built executable at bazel-bin/path/to/executable/executable
A full example:
{
"version": "0.2.0",
"configurations": [
{
"name": "(gdb) Launch Debug",
"type": "cppdbg",
"request": "launch",
// path to the most recently built version of executable
// this should be built with `bazel build -c dbg //path/to:executable`
"program": "${workspaceFolder}/bazel-bin/path/to/executable/executable",
"args": [],
"stopAtEntry": false,
"cwd": "${workspaceFolder}/bazel-bin/path/to/executable/executable.runfiles/{workspace-name}",
"environment": [],
"externalConsole": false,
"MIMode": "gdb",
"setupCommands": [
{
"description": "Enable pretty-printing for gdb",
"text": "-enable-pretty-printing",
"ignoreFailures": true
}
],
"sourceFileMap": {
"/proc/self/cwd": "${workspaceFolder}/bazel-{folder-name}"
}
}
]
}
Most of this is covered in this useful post (which also shows how to automatically build your executable using tasks.json):
https://shanee.io/blog/2019/05/28/bazel-with-visual-studio-code/
Over the weekend I had installed a gcc through the MSYS2 bash. I set it up in VS code and have it working properly. I even had the GDB working (yes I know this is a debugger). But, my main question is, is it possible to use the debugging function in VS code to debug rather then GDB. Pressing F5 it pulls up the launch.json file and gives me launch: program 'enter program name, for example c:\School\a.exe' does not exist .After some research I see you give it a file to the args to allow it run in debugger. When I do this though I can't seem to either give it the right file or make it work overall. I am also using a.exe rather than a.out. I'm unsure if this has effect.
{
// Use IntelliSense to learn about possible attributes.
// Hover to view descriptions of existing attributes.
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
{
"name": "(gdb) Launch",
"type": "cppdbg",
"request": "launch",
"program": "enter program name, for example ${workspaceFolder}/a.exe",
"args": ["C:\\School\\CSE340\\project2\\main.cpp"],
"stopAtEntry": false,
"cwd": "${workspaceFolder}",
"environment": [],
"externalConsole": true,
"MIMode": "gdb",
"miDebuggerPath": "/path/to/gdb",
"setupCommands": [
{
"description": "Enable pretty-printing for gdb",
"text": "-enable-pretty-printing",
"ignoreFailures": true
}
]
}
]
}
VS Code does not have an internal debugger (see here). You need to use GDB or the visual studio debugger (if you have the latter).
In your launch.json you need to modify the entries:
"program": this is the path to the program you want to debug, i.e. your compiled program (can be a relative path to your project folder)
"miDebuggerPath": this is the path to GDB
"args": these are arguments, you want to pass to your programm for debugging purposes, i.e. you can leave this blank
So the launch.json file for you would look something like this:
{
// Use IntelliSense to learn about possible attributes.
// Hover to view descriptions of existing attributes.
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
{
"name": "(gdb) Launch",
"type": "cppdbg",
"request": "launch",
"program": "${workspaceFolder}\\CSE340\\project2\\main.exe",
"args": [],
"stopAtEntry": false,
"cwd": "${workspaceFolder}",
"environment": [],
"externalConsole": true,
"MIMode": "gdb",
"miDebuggerPath": "C:\\MinGW\\bin\\gdb.exe", // Path where your gdb.exe is located
"setupCommands": [
{
"description": "Enable pretty-printing for gdb",
"text": "-enable-pretty-printing",
"ignoreFailures": true
}
]
}
]
}
${workspaceFolder} is a path variable to your workspace and seems to point to C:\\School\\, so maybe you'll need to modify the value of "program" to point to the application that you want to debug. You could also specify the absolute path to your program.
Also, do not forget to compile your code with debug-flags (-g), these are needed by GDB in order to step through the code. For example:
g++ -g main.cpp -o main.exe